As creating value through digital technologies turns into the ‘big question’ that enterprises today are faced with, top leadership’s gaze has turned towards successful reinvention. This entire exercise falls under the remit of Enterprise architecture (EA) and requires navigating the right course amidst organizational complexities and the existing IT landscape while making sure the scale and transformation suitably augment enterprise plans. It is what’s keeping the senior executives on their toes. This insight offers a comprehensive view of what it’s like to build modern enterprise architecture.
What Is Enterprise Architecture?
Gartner defines Enterprise architecture (EA) as “a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes.”
Enterprise architecture helps organizations recognize various approaches to enhance their performance by analyzing and evaluating the enterprise’s IT and business capabilities. It starts by taking a thorough look at its entire functioning, including ‘processes, people, and technologies, followed by developing a plan and approach to transition into its desired state.
In other words, EA entails putting in place an organization-wide structure comprising strategies and goals to drive change by bringing together every aspect of the organization right from departments, data, applications, systems, policies, and processes, and chalk out a path to reach a targeted business state. And in doing so, it considers the extent of business disruptions while minimizing the risks and costs involved.
Enterprise Architecture Approaches: The Past and Present
There has been a tremendous change in how EA practices have evolved from the past to the present. The way products and technologies were mapped out and designed, orchestrated, and formalized was drastically different during a decade or decade and a half back; the basic distinction has been to go from ‘inward’ to ‘outward’ technological disruptions. Here’s a brief comparison on a few parameters.
The Context for Enterprise Architecture
As an operational element in the business, an Enterprise Architecture (EA) program has a context, which implies that architectural endeavors must be in tandem with the organization’s strategic plans. The implementation initiatives must also be carried out in a way that they are with regard to the enterprise architecture. It is therefore vital to model and envision the alignment of the enterprise architecture
1. Strategic Context
Architecture should be linked to Strategic Plans in order to ensure that the architecture will ultimately aid the organization in delivering value. Therefore, it is imperative that the business architects should be a part of long-term strategic enterprise objectives, future plans, high-level discussions, and decisions. The architects have various tools and technologies at their disposal that make sure the architecture fits with the corporate vision, will, and philosophy. The architects build a task force that visualizes a strategic plan and its drivers while mapping the activity over a period of time. The strategic plan is also updated and reviewed from time to time for setting the tactical direction.
2. Planning and Implementation Context
Since enterprise architecture must ultimately drive value and aid business by designing the architectural model and ensuring success, governance is an integral part of the process. It must be made sure that the proposed architecture is understood in no uncertain terms across the board and is appropriately followed. The implementation is what takes the organization from a baseline state or the present state to the targeted or the desired state. Most critical to the implementation initiative are timely performance reviews, continued adherence to future plans, as well as compliance initiatives. Other activities may include importing content, creating data repositories, streamlining processes, discarding old methods, and building new norms.
3. Scope of Architecture
From creating timeframes to sticking to the enterprise context, degree of detail, charting a cost and technology boundary, and getting a nod by stakeholders—all are intrinsically connected to the scope of enterprise architecture. The scope decides the extent and expanse of the intervention. Hence, its chances of success are associated with it.
4. Scope of Time
Time is of essence in every EA effort, just as it is in any implementation. Timelines are connected to the organization’s operations and functioning and have a cost associated with them. Timelines for EA implementation can span anywhere between one to five years depending on the size and scale of the enterprise. Also, different roadmaps overlap over each other, and all are tight-knit and connected. So, time scope is essential at every level in the plan.
5. Scope of Detail
The right degree of detail is essential. May ambitious architectures, which are too complicated and require many design and implementation decisions to be made by the teams themselves, may offer the best solutions, but might not be suitable for the whole organization, as they may not have the stakeholder or manager buy-in. Its opposite might pose the problem of excessive control and oversights. To simplify the EA detail, architecture team works with all stakeholders, implementation teams, collaborators to determine the desired level of detail.
6. Company Scope
Being a costly endeavor EA’s company-wide scope encompasses whether all the desired components of the business are being transformed and are getting positively impacted by the change. Whether organization functions such as finance, sales, marketing, production, operations, etc., are getting impacted and what will be the nature of change is critical to the enterprise's success, and hence falls under the purview of company’s visualization of scope.
7. Scope for Stakeholders
Stakeholders are a wide bunch constituting of internal or external people and are therefore the real beneficiaries of the transformation that will occur by installing a new EA. They must be always tuned into the progress of the EA work. A clear mechanism must be crafted to ensure that EA’s scope for stakeholders is charted out before the project begins, including how the change will be driven, goals will be accomplished, objectives would be achieved. And after the change is affected, the stakeholders can evaluate it.
Types of Architecture
Enterprise Architecture can be broken into several components. They can range from Information, Application, Technology, Security, Geospatial, and Social. However, for simplicity, we will restrict our discussion to only the first three architectures.
1. Information Architecture
Information flow is key to most business functions. Getting a grasp of how information can be made empowering for an organization is the job of the architects. Which information assets are to serve as master records, which ones are needed to be made accessible to which processes and departments, which technology component will help in achieving information objectives—everything has to be thought through by keeping in mind the purpose, associations, and relationships between information and business.
2. Application Architecture
The application architecture accomplishes a crucial part of the enterprise architecture exercise; it selects suitable applications, targets and transforms processes, while transporting and storing up information. This includes the way these applications interact with each other and performs actions. Therefore, what is needed are business process illustration and capability mock-ups about whether the chosen application will manage the existing data and business artifacts and will be favorable in putting the business in the desired future state.
3. Technology Architecture
Technology architecture buttresses all the other essential architectures by providing a solid foundation in terms of offering physical or virtual infrastructure support. In addition, it helps install application services that ultimately extend support to business, inter-departmental functioning, and processes.
Architecture Models
One of the primary purposes of architecture is developing logic to map business onto IT capabilities. Therefore, creating a model is a complicated exercise since many layers of constructs must be considered in order to cover every requirement in the highest level of detail. The models or architecture are generally based on the integration of overall reference architecture (or the established representation of the architecture) styles such as Object Management Architecture (OMA) and Service-Oriented Architecture (SOA), Business Process Management (BPM) and SOA, etc. Therefore, several architecture models might be used to achieve the desired view. In addition, models are usually based on blueprinting processes that are already standardized after high-level design and analysis execution in an enterprise. However, in case of non-existence of any standard blueprinting techniques, architecture models may become highly customized. In such a scenario, many questions need clarity:
- What concepts are being explained by the models?
- Are the concepts abstract?
- Is the model presenting a concrete design?
- Do the symbols on the diagram represent anything?
- Which architecture domain is modeled?
- Is the design for the entire organization, project, or a particular LOB (Line of Business)?
- Does the model depict the present, desired, or transition architecture?
- In the case of a Transition architecture, what all modifications in the IT environment are planned?
Architecture Blueprinting
As the name suggests, an architecture blueprint is an architectural illustration. It is developed by using a coherent representation to depict a probable model of the IT environment as-it-is, to-be, or in-transition. In contrast with Unified Modeling Language (UML) models, that are software engineering illustrations—blueprinting happens at an architectural level, and offers the right context that is required to see the bigger picture. Similar to the blueprint of a physical building, software blueprinting makes it easier to visualize the size and scale of the enterprise architecture in a minutely detailed fashion. In other words, they allow the architects to see the entire design of the building alongside every single floor in the structure and how every floor and every room occupies a unique space but also fits into the entire plan.
Use Case
Pimcore Global Services Helped Northgate Markets in North America by overhauling its entire Enterprise Architecture
PGS helped Northgate markets and its entire group of companies, including the Grocery store, Financial services, and Real estate that were facing challenges such as high capex, lack of transparency, multiple sources of data, low end-user visibility and reach, data inconsistencies, poor interoperability, little employee satisfaction, and low customer engagement.
PGS provided Northgate Markets with Consulting, Application development and support, and Cloud migration and support. PGS started by reviewing the application landscape and created the right technology strategy, providing an enterprise-level architectural roadmap for digital transformation. This was followed by creating end-to-end solutions to accelerate and improve decision-making operational efficiency and optimize overall processes.
PGS carefully looked at every component in their Business Application Stack, including its Public Access Apps, Business Apps, Aggregator Platform, and In-house Apps.
The business transformation also included the migration of more than 300 servers from two different DCs and AWS cloud to GCP (Google Cloud Platform). The built enterprise-level architecture had high availability, scalability, and offered 24/7 Operation Service Management.
As a result, Northgate markets reduced Infrastructure cost by 70%, decreased time-to-market,
reinforced employee engagement, enhanced marketing opportunities, adhered to compliances better, offered an enriched customer experience, and increased their productivity.
