I have been asked some interesting questions over the years around the importance of Enterprise Architecture in organizations. Some CIOs and IT executives have expressed apprehension towards enterprise architecture, labelling it as; “Hairy Fairy”; “Pie in the Sky”; “Not Strategic Enough”; “and Not Operational Enough” and so on. This compelled me to try and demystify this subject that happens to be a passion of mine.
My initial understanding of Enterprise Architecture was largely influenced by the literature I have read and studied and some practical projects I have done over the years. Finally, about eight to nine years ago, I concluded that enterprise architecture was the mechanism of bridging the gap between business strategies and objectives with IT operations not excluding the management of the “The Business of IT”. It was not quite clear at that time what the concept “Architecture” was really about.
I came to realize that my understanding was not far off, but required a closer look at the journey of bridging that gap, the techniques employed, the plans developed, the methodologies and tools used, the end to end management processes, the risks associated with enterprise architecture and, all of these factors packaged provided a better picture of: “what organizations want to achieve, and the route organizations take to achieve objectives”.
The idea of this article is not to recreate or reengineer enterprise architecture school of thoughts, it is also not to deep dive into the subject, but to highlight key architectural concepts and establish a “Good Enough Enterprise Architecture” and finally my humble opinion on how to quickly realize value out of EA and what it entails based on industry wide frameworks, standards and practices.
My architecture idol, Mr. John A. Zachman once said: “CEOs declare that the biggest challenge facing the modern enterprise is “change”. A quick review of the history of all the known disciplines that deal with complex objects (things) reveals that change start with the engineering descriptions of the things. There is no way to change hundred story buildings quickly (or safely) without starting with the building plans. This no way to change Boeing 747’s quickly (or safely) without starting with the product description. There is no way to change automobiles, computers, integrated circuits, oil refineries, battleships, telephone networks, programs, or any other complex thing quickly (of safely) without starting with the descriptive representation of the thing you want to change.”
Let us look at the top 6 questions I often get asked.
· “What is Enterprise Architecture: - The Definition?”
· “Why do we need Enterprise Architecture”?
· “What is the scope of Enterprise Architecture”?
· “What does Enterprise Architecture result in?”
· “What skills do you require to be an enterprise architect?”, and arguably the most important question,
· “What are the benefits of Enterprise Architecture?”
I will attempt to answer these questions in this article mostly using reference models that I have personally conducted over the years and also reference other practitioners’ work.
But before we answer these questions, let us first define what enterprise architecture is:
“Enterprise architecture is the process of translating business vision and strategy into
effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise's future state and enable its evolution. The scope of the enterprise architecture includes the people, processes, information and technology of the enterprise, and their relationships to one another and to the external environment.” – Gartner: ID Number: G00156559
“Enterprise Architecture is the continuous practice of describing the essential elements of a sociotechnical organization, their relationships to each other and to the environment, in order to understand complexity and manage change”: Dr. Sam Vaknin
“Enterprise Architecture is explicitly describing an organization through a set of independent, non-redundant artefacts, defining how these artefacts interrelate with each other, and developing a set of prioritized, aligned initiatives and road maps to understand the organization, communicate this understanding to stakeholders, and move the organization forward to its desired state” Enterprise Architecture Center Of Excellence. http://www.eacoe.org/index.php?gclid=CPOao6CqvbYCFU7MtAoda0QArw
There are a number of definitions of enterprise architecture out there. I would argue that the principles of defining EA for an organization should be based on what and how that organization wish to achieve its business objectives, strategic imperatives and operational efficiency.
It has been 14 years practicing enterprise architecture, I am now comfortable to coin my own definition of enterprise architecture and that will answer the first question “What is EA?
“Enterprise architecture is the practice of which organization employ to achieve business objectives, strategic imperatives and operational efficiencies across the organization and its ecosystem through the use of architectural frameworks, architectural principles, business & IT roadmaps and transition plans to accomplish the desired business state”. – Bangi Magashula
1 Enterprise Architecture Helicopter View
This section of the document answers the question: - “Why do we need Enterprise Architecture”? Enterprise Architecture ensures enterprise-wide alignment of business and technology domains by following a well-defined and structured approach, EA is a structured and measurable discipline that ensures business imperatives and strategic directions are aligned with the operational strategies including Information and communication technologies. EA coordinates business objectives and functional activities including external processes and influences. The diagram below depicts at a high-level how EA structures uncoordinated efforts into architectural domains that will be discussed in the next section. EA also provides a consistent framework of current and future architectures. IT provides standards and guidelines for new technology introduction, improves the consistency, accuracy, timeliness, integrity, quality, availability and access of information across the enterprise reducing software and data redundancy:
Figure 1: High-Level View of Enterprise Architecture
EA reduces application implementation re-work and provides for greater reliability at implementations and updates improving accuracy in scheduling software development / implementation. IT also highlights opportunities for building greater quality and flexibility into applications without increasing cost. EA also reduce information systems complexity by standardising on architectural platforms providing architectural views that help communicate the complexity of large systems to all business stakeholders. The implementation and streamlining of enterprise architecture improves alignment of IT and business through the integration of architectural layers and define EA roadmap that will support business strategy and objectives:
• An EA framework and standards enables the effective evaluation of emerging technologies and the integration of new technologies
• Expedites the integration of legacy, migration, and new systems
• EA improves communication between the business and IT organisations through a standardised vocabulary, framework and roadmap
Below is a generic representation of enterprise architecture coverage based on The Open Group Architecture Framework (TOGAF) of which this article will be largely based. Architectural domains and reference models will be covered in detail in Section 3 of this document.
Figure 2: Enterprise Architecture Coverage
1.1 Business Strategies & Government Mandate
This section of the architecture outlines the business strategies and objectives of the organization. These objectives are then cascaded down the business units for execution and management. Some organizations capture these strategies, goals, objectives and mandates in different areas of the business (e.g. Chief Executive Officer is responsible for developing strategies and overall directions for the organization, and the Chief Operations Officer is responsible for the overall operation and execution of the overall business strategies.). It is then business architect responsibility to ensure that IT and other support, operations and execution platforms are aligned to these strategies.
1.2 Business Architecture
Business strategy typically defines what organization want to achieve, by using building blocks, such as goals and drivers, location, business actors, functional decompositions, business processes, performance matrices and the metrics for success and the business architecture describes and develops plans of how to get to the future business state supported by IT and other functions. Business architecture is also responsible to developing contextual architecture at a project level, then disseminating that architecture to relevant domain architects to develop conceptual, logical and physical level architectures.
1.3 Information / Data Architecture
Information architecture deals with the combination of organization, labelling, and navigation schemes within an information system and the structural design of an information space to facilitate task completion and intuitive access to content it also includes the art and science of structuring and classifying content such as web sites, intranets, and content repositories to help people find and manage information.
Information architecture also defines the domains sub-reference models such as Meta data management model, information exchange models, taxonomy definitions, content creation, information reliability, information monitoring models and search amongst other things. The most common function of this domain is creating and managing business intelligence and reporting architecture. Information architects also use reference models to represent the information architecture coverage and information flow plans and the management thereof.
1.4 Application Architecture
The role of the application architect addresses the conceptual/planning level even logical level of the application architecture in collaboration with other architects focused on the needs of the technology, business and information architectures. The application architect ensures that the application portfolio evolves at an appropriate rate and does not become unviable as the other related architectures change. Application architect also provides the reusable standards, guidelines, patterns and frameworks to application development projects, including those related to application architecture.
A concept that defines the characteristics, styles, and interactions among one or several applications which is depicts on amongst other things, component interaction, technical & data architecture, business component applications, guiding principles, services, integration and processes:
At the project-level, application architects make sure that all aspects of the application solution architecture are optimized (as much as possible given other constraints of time and budget) by working with subject matter experts (SMEs) in the areas of technology, information and application architectures and disciplines. The application architect is the SME focused on designing application interfaces and software services to maximize reuse based on the business processes and governance rules for sharing
1.5 Infrastructure / Technology Architecture
Technology or infrastructure architecture or 'layer' defines and specifies the interfaces, parameters, platforms, services and protocols used by other domain architectural layers. Platforms and Services provide a layer of abstraction from the actual products that deliver them. Either one, or both, may be combined in realizing a particular pattern.
Components are the actual “bricks and mortar” of the infrastructure. They are the things that are most commonly thought of as infrastructure.
· Components are exemplified by:
§ Operating systems (Windows, z/OS, Solaris, HPUX, AIX, etc.)
§ Hardware platforms (Intel, z/Series, Sparc, etc.)
§ Middleware software (WebSphere MQ Series, CICS Transaction Manager, WebSphere Application Server, etc.)
§ Network Devices (Switches, Routers, etc.)
§ Storage Devices (DMX1000, Direct Attach IDE, Direct Attach SCSI, etc.)
· Components are characterized by:
§ A description of their function.
§ Specific vendors, contracts, and products.
§ Service Level Objectives appropriate to the component.
2 Enterprise architecture drivers
This section attempts to answer the question “Why do we need EA”? Organizations and government departments are driven by the different strategies, objectives and mandates that are informed by a number of internal and external factors, one would have to focus on “A” organization to conclude what their business drives are. There are common themes across industries that raise the need and necessity for enterprise architecture in organizations. Some of which are business led changes and some IT led changes.
The following are examples are some of the business led changes that will require a certain level of enterprise architecture planning and execution.
· Operational Efficiency & Productivity: - Organization may need to re-engineer and improve their business processes to enable better productivity and increase to the financial bottom line. This may also include consolidation and streamlining of IT assets, adoption of new operating, support, delivery and governance models. These mechanisms are categorized under the business architecture domain, although some of these function span other functional areas, it is however, important for the business architecture role to understand and develop execution plans.
· Competitiveness: - Time to market and unique value proposition enables organization to be positioned in an advantage in a very competitive industry. Enterprise architecture defines functional services or products and streamlines processes and technology to accelerate delivery of services or products optimally.
· Legislation:- Laws and legislation change frequently, an agile enterprise architecture ensures that organizations comply with changing legislation easily by imbedding legislation and rules into everyday business processes execution and technology enablement
· Cost Reduction: - As already mentioned. Agile enterprise architecture streamlines processes, people and technology to efficiently and profitably manage the delivery of services and products through process improvement, technology rationalization and portfolio management, and through effective definitions of roles and responsibilities
· Business and IT Alignment:- Arguably the most important value of enterprise architecture, is that, it ensures that business objectives through the decomposition of value chains, functional areas, business process and support application and executing infrastructure supports business imperatives.
2.1 Why Is Enterprise Architecture Important?
I like to look at the importance of Enterprise Architecture in the three “Buckets” of challenges business often face, that is, Business; Process and Technology and how EA address those challenges. The people part will be covered under section 5. The following table highlights enterprise architecture value proposition to most organization’s challenges:
Business Bucket
| |
Business Challenges
|
Enterprise Architecture Value Proposition
|
Low accountability and ownership
|
Architecture decomposes functional areas & responsibilities by role. EA also defines data ownership and stewardship.
|
Duplication of effort
|
Portfolio rationalization and management with associated process owners ensures that there are no people or application services duplication.
|
Laid back adoption to change
|
EA governance, Architecture review boards, Project/Portfolio management with close corporation with change management ensures that adoption is enterprise wide and managed effectively
|
Skill shortage
|
EA “cross hairs” is centred on People; Process & Technology. EA helps map what skills are required and should be retained for which processes and technology support.
|
Restricted sharing of information across businesses
|
EA breaks the “Silo” approach by centrally managing the execution of business functions and services. The information architecture domain especially governs the use and distribution policies & procedures around data & information in an organization.
|
Complex business models/ rules/ methods/ processes
|
EA uses architecture tools to map and simplify business models/processes and associated relationships with rules to clearly depict business interaction with its ecosystem
|
Poor inter-departmental communication
|
EA governance structures and set agendas are on-going platforms and forums to ensure that changes to business strategies and operations are aligned all the times
|
Process Bucket
| |
Business Challenges
|
Enterprise Architecture Value Proposition
|
Lack of process documentation and automation
|
EA tool is a central repository for all processes in an organization. It is used to map, improve and re-engineer processes.
|
Distrust of information shared
|
As mentioned above, EA helps streamline processes with associated actors, rules and workflows. This ensures that information owners take accountability of the integrity of the information shared.
|
Partial segregation of duties
|
Functional & Process are clearly mapped to owners through the use of “Swim Lanes” and actors or roles to clearly define the responsibilities of duties during the execution of all processes.
|
Technology Bucket
| |
Business Challenges
|
Enterprise Architecture Value Proposition
|
Loss of critical Business IP when contractors exits from projects
|
EA ensures that IP generated is stored in a central repository and rendered by business units through portal services.
|
Insufficient understanding of business projects & IT Alignment to business
|
This is perhaps the biggest value proposition of EA. EA ensures that IT executes on business services that are aligned to business strategies through the use of decomposed processes, value chains and functional decomposition models.
|
Restricted system integration
|
Application landscape and integration (Web Services, ESBs or Point-to-point) are managed by EA application domain architecture to ensure that systems that need to talk to each other securely are managed, monitored and reported on concisely.
|
Constraint channels to external entities and vendors
|
EA is a central point of all the applications and hardware infrastructure in an organization. This ensures that SLAs are met and monitored from a central place.
|
The picture below is a high-level representation of how enterprise architecture aligns business and IT. This is arguably the most important and valuable service that enterprise architecture offers to organizations.
Figure 3: Business & IT Alignment
In the past, many applications management units identified business capabilities with business sub-processes (often at level 2). Modern business architecture departs from this view, placing them a level of abstraction above business processes. Business capabilities provide a bridge from strategic priorities to business planning and business case creation. Business capabilities are also more stable than business processes because they change slowly, capabilities provide a good lens for viewing strategy at different time scales and for prioritizing and budgeting decisions.
1 Breath & Width of Enterprise architecture
1.1 Business Architecture
We have discussed a bit of enterprise architecture domains, what EA is and what the possible EA drivers are. Let us now focus on what the scope of enterprise architect really entails and also answering the question: “What is the scope of Enterprise Architecture”?
The enterprise architecture domain building blocks really depended on the ecosystem and the stakeholder’s views and concerns. As we have established that role of business architecture is tasked with the planning and developing execution mechanism of business strategies and goals amongst other things. Some of the business architecture components are:
· Business Operating Model – This is typically how the overall business and business units are structured in executing and managing business strategies
· Business Services - this describes the products and services an organisation offers and sells to its customers.
· Business Information - this describes the structure of the business information needed by each business processes and information created by business processes. Includes knowledge and meaning.
· Business Processes - this defines the business processes, organisation structure and roles that are required to define and operate an organisation.
· Business Events - this defines the triggering events received by the organisation to which it must respond, and the outgoing notification events that an organisation creates.
· Event Value Chains - this defines the flow and sequence of business processes/activities that are triggered by a business event and resulting in added value.
· Organisation Architecture - this defines the organisation structure, roles and responsibilities that are required in an organisation.
· Business Functions - this defines the functions and capabilities that are required within the organisation
· Organisation Services - this defines the services that are provided by people (as opposed to those provided by applications).
· Capabilities - this defines the functions, behaviours and services that may be provided by the organisation units (internal Actors and Business Roles)
Most organization use architectural reference models to document their current business or technology state and their future state. The diagram below is an illustration of the business architecture reference models where building blocks within the reference models are sub-reference models in their own right, as it will be demonstrated by the Business Capability Map and the Business Process Management building blocks as part of the business architecture domain
Figure 4: Business Architecture Framework (source TOGAF)
“Business Architects design, obtain approval, translate and administer the implementation and ongoing improvement of the transformational business initiatives that enable organizations to convert strategy into commerce and prevail in the marketplace. Strategists are primarily concerned with the direction of the organization, Business Architects with the design of its dynamic structure, and line managers with driving results”. ------ Paul Arthur Bodine
One practical methodology of understanding what business units of an organization do is to develop a business capability heat map. This means documenting every single business unit’s objectives based on the overall strategy and mapping it to how people, process and technology execute on those objectives. The business capability mapping helps quantify end to end the operational performance of the organization thus planning on improvement areas and processes and possible technology and people.
Capability Map Variable
|
Description
|
Architectural Significance
|
Department
|
This column describes the business unit (BU) in the organization (e.g. Finance)
|
Design of the organization structure and associated KPAs
|
Functional Area
|
This is a functional area within a business unit (e.g. Debtor / Creditors within finance)
|
For organization structure and associated KPIs
|
Business Service (KPA)
|
This is a service that the functional area performs on a daily basis and gets measured on (e.g. Payment Collection)
|
Development of organization wide business service catalogue for scorecard reporting
|
Business Service Owner
|
This is the role tasked to oversee the execution of this business services (e.g. Bookkeeper, CFO, accountant etc
|
Assignment of data and information ownership and stewardship and also tactical decision making and process ownership.
|
Application
|
Name the Technology /Application/Platform that is supporting or executing the business service or KPA. This is also used to baseline technologies across the organization. (I.e. What technologies are out there and what are they used for? (e.g. SAP FI, Pastel etc)
|
This forms basis for Application& infrastructure Portfolio Management for financial and support analysis and reporting
|
Issues / Opportunities
|
This section covers possible system or process concerns and improvement (e.g. system interface, processing capability, reporting capabilities, automation, etc).
|
This captures the “Nice to have” or “Must Have” that could be used as motivation in a business cases, transitioning road maps & project portfolios.
|
People
|
People executing this business service experienced? Do they require training? Mentoring programs?
Are people generally satisfied with their job? This could be used to benchmark skills pool of the organization and what resources are needed to bring on board.
|
Career development, staffing requirements and input to HR people’s management activities
|
Process
|
This section establishes whether processes are mapped and documented and assigned process owners, establish if the process has been recently been improved or re-engineered. Also ask if the process is manual or automated to ascertain maturity. Also ask if people where executing this process where trained on the process its self (How to). Does the process have exemplary artefacts / outputs for quality reference? Does the process have a time stamp against it for completion? Are all components of the process flow integrated? Are the outcomes of the process predictable? Do we have known remedies if the predicted outcomes do not come out as expected.
|
This will isolate processes that require mapping and improvement initiatives. This will also establish which processes execute what business service for which functional area and the owner of those processes for scorecard analysis and reporting
|
Technology
|
Technology or Systems = Applications + DB + Infrastructure: Application COTS or Bespoke? Version of the application?
Can the application be supported solely organization or vendor and how active is the support SLA? Is there training available for the application/DB. Does the infrastructure need refresh? DO SLAs still exist for the infrastructure? Does the infrastructure need optimization? Are the support, management and security measures and processes in place to ensure no disruption of business services?
|
This is the lowest level and most significant to establish if infrastructure is maturated and fit for business purpose.
|
Business
Impact.
|
Should this business service seize to exists or be unavailable what would be the implication to the business (financially, operationally, productivity). Should the combination of Process / People / Technology be of “Sub Standard”, what implication would this have to the business (financially, operationally, productivity)
How many staff members, customers, suppliers, partners, and the entire ecosystem does this business service impact again (financially, operationally, productivity)
|
This ensures that redundant, obsolete or changed business services are identified based on their importance. Also ensures that the meaningful tasks and business services are performed to eliminate mundane and unnecessary activities.
|
1.1.1 Business Process Management
Business Process Management is an integral component of the business architecture domain. Business process management cconcerns the transformations that are performed in the Enterprise answering the ‘How’ questions. IT also addresses these in terms of the Business Processes Flow Diagrams, Activities, Workflows (Value Streams), Scenarios and Business Events. The diagram outlines the business process management framework:
Figure 6: Business Process Management Framework
Business strategies and activities are decomposed into granular value chains and supporting core and sub-processes which are executed by systems/applications (software) hosted by technology infrastructure (e.g. hardware, networks, security, and communications technologies). These business imperatives are reported and monitored through SLA’s / OLA’s and Balanced Scorecard with associated KPI’s to ensure alignment with the business strategies.
1.1 Information / Data Architecture
1.1.1 Information Architecture
Wikipedia defines Information architecture as “the art and science of organizing and labeling data including: websites, intranets, online communities, software, books and other mediums of information, to support usability”.
Information architecture also describes the ownership and stewardship of information usage, categorization, definition of information principles and arguably the most important, the security and protection of organization’s digital assets. The framework below highlights some the information architecture building blocks.
Figure 7: Information Architecture Framework
I will not be delving in detail on the above reference model as it is a guide to ensure that elements that cover information architecture are highlighted, defined and taken into consideration when building an information architecture domain.
Business intelligence is perhaps the most referred to building block within the information architecture domain. As previously mentioned these building blocks are reference models in their own right as depicted by the Business Intelligent Reference model below.
Figure 8: Business Intelligence Reference Model
The data components of a BI architecture include the data sources that corporate executives and other end users need to access and analyze to meet their business requirements. Important criteria in the source selection process include data currency, data quality and the level of detail in the data. Both structured and unstructured data may be required as part of a BI architecture, as well as information from both internal and external sources.
Information management architectural components are used to transform raw transaction data into a consistent and coherent set of information that is suitable for BI uses. For example, this part of a BI architecture typically includes data integration, data cleansing and the creation of data dimensions and business rules that conform to the architectural guidelines. It may also define structures for data warehousing or for a data federation approach that aggregates information in virtual databases instead of physical data warehouses or data marts.
The technology components are used to present information to business users and enable them to analyze the data. This includes the BI software suite or BI tools to be used within an organization as well as the supporting IT infrastructure – i.e., hardware, database software and networking devices. There are various types of BI applications that can be built into an architecture: reporting, ad hoc query, data mining and data visualization tools, plus online analytical processing (OLAP) software, business intelligence dashboards and performance scorecards.
1.1.1 Data Architecture
Data architecture improve decision making and also improve availability and accessibility of organizations information and services. It also structures data in a consistent and understandable manner across all business units. A Data Architect is an increasingly important role. It is a natural evolution from Data Analyst and Database Designer, and reflects the emergence of Internet Web Sites which need to integrate data from different unrelated Data Sources. The Data Architect needs to be able to have an end-to-end vision, and to see how a logical design will translate into one or more physical Databases, and how the Data will flow through the successive Stages involved. He or she will need to be able to address issues of Data Migration (Validation, Clean-up and Mapping), and will need to understand the importance of Data Dictionaries.
Figure 9: Data Architecture Reference Model (Source: Data Enthusiast by Joshua Burkhow)
Data architecture defines how data is stored, managed, and used in a system. It establishes common guidelines for data operations that make it possible to predict, model, gauge, and control the flow of data in the system. This is even more important when system components are developed by or acquired from different contractors or vendors. In particular, data architecture describes
· how data is persistently stored
· how components and processes reference and manipulate this data
· how external/legacy systems access the data
· interfaces to data managed by external/legacy systems
· implementation of common data operations
Properly executed, the data architecture phase of information system planning forces an organization to specify and delineate both internal and external information flows. These are patterns that the organization may not have previously taken the time to conceptualize. It is therefore possible at this stage to identify costly information shortfalls, disconnects between departments, and disconnects between organizational systems that may not have been evident before the data architecture analysis. (Source: Data Enthusiast by Joshua Burkhow)
1.1 Application Architecture
Application architecture can be decomposed to Conceptual, Logical, and physical model associated with integration & messaging standards and governance framework for application development, implementation & management. These building blocks are reference architectures in their own right.
Figure 10: Application Architecture Reference Model
The deployment of application must follow a set System Development Lifecycle integrated with service support and service delivery process (e.g. Change, Release, and Configuration Management).
For more than 30 years, the IT portfolios of large organizations have been expanding. This stems from both increasing business needs and the eruption of new technologies on the market. With the increasing focus on corporate globalization, efficiency, productivity and cost reduction, CIOs face even more complex challenges to rationalize their IT portfolio.
You not only need to optimize the architecture of your IT systems, you have to optimize their deployment within the organization. Numerous applications are redundant, misused or even obsolete. Others are meant to be identical and are specifically configured or deployed. More important than the associated maintenance costs, the poor management of application portfolios makes the IT systems vulnerable, hindering their required evolution. The economic and optimization results are so important that they justify the investment in new governance practices.
IT is therefore the responsibility of the application architect to create a framework to rationalize applications more often than in the past years. The framework below is an application rationalization framework that the application architect could utilize to perform an application rationalization project.
Figure 11: Application Portfolio Rationalization Framework
This is the benefit of new application portfolio management (APM) solutions. They provide multiple criteria analysis, compatible with the complexity of the modern application landscape. They ensure a clear and comprehensive view of all deployed components (including their cost, their contribution to the enterprise performance, etc.) to address the impact of rationalization efforts. These APM solutions allow you to take the budget constraints and business continuity for each operation into account by building scenarios for application portfolio evolutions. Implementing application portfolio management practices in IT departments should be a priority. This is a legitimate opportunity for CIOs to justify the necessary governance tools to drive IT transformation. Below are some of the benefits for an application architect to perform an application portfolio management or rationalization:
Reduction of costs and complexity: - Information about the application, including redundancies, overlapping and unjustified costs, needs to be provided to make informed decisions about potential changes to the application including modification, retirement, maintenance, etc. The financial and economic elements of an application portfolio are important considerations when assessing the value of the applications. Setting cost savings goals and measuring the impact of changes to the legacy systems is important to mitigating unnecessary maintenance costs.
Risk and compliance management: - Application failure can vary widely. They can be associated with technical performance, support interruption, lack of technical skills and technology obsolescence. Consequences of failures cover a large spectrum, including inability to meet business requirements, non-compliance with regulatory requirements, or vulnerability against cyber-attacks. By keeping control of your application portfolio, according to your criteria, you are able to anticipate failures.
Appropriate assessments of how your application portfolio is deployed throughout the company’s operations provide a key opportunity to identify the most critical applications for your organization and align them with business continuity requirements. APM speeds up the implementation of a complete and effective business continuity plan that is based on valid information provided by the people in the field.
Better investments that are better qualified: - Limited budgets need to be allocated to valuable assets and investments for the business first. APM provides all the elements to support decision-making in order to guide the investment choices and associated budget planning.
Outsourcing part or all of your IT resources is one of your important strategic decisions. For this purpose, APM also provides unique information to make valid decisions about the sourcing strategy and cloud/ SAAS implementations, especially from a financial perspective.
Alignment of IT assets with business challenges: - Once you are able to align the contributions of your IT resources with the business, you change the scale of returns on investment. Thanks to APM, which provides clarity to the relationship between applications and business, application architects can establish a stronger position to promote projects. The potential savings on application maintenance opens budgets to use toward serving business needs and improving operations.
1.1 Technology Architecture
Technical architecture helps in identifying what infrastructural requirements necessary to enable other functional models like data, information & application to operate harmoniously. These are normally physical architecture depicting infrastructure landscape. Infrastructure architecture planning is an on-going process, not a single static concept. It is a methodology for identifying and documenting current business and infrastructure environments, projecting information requirement to the target environment. Throughout this planning process, that will determine:
· How well current infrastructure architecture meets the objectives of the client’s business operations
· What infrastructure reference model best meets the requirements of the organization’s long term business plans
· The best transition strategy to migrate from the current business environment to the planned business one.
Figure 12: Technology Architecture Reference Model
This reference model specifies the elements of the client’s target environment infrastructure architecture in the form of templates. During the delivery of business services, templates will be developed for each of the following target environment elements:
· End – User Service Architecture: – Defines major, common applications and infrastructure technology tools needed by various classifications of end-users throughout the organizations. This includes standards and specification for:
o Desktop processing
o Infrastructure delivery strategies and delivery strategies and devices
o End-user interfaces
o End-user services classifications
· Server (Processor) Architecture: - Specifies the logical and physical hardware and software capabilities for business functions servers. This includes standards and specification, by servers at each business level:
o Desktops
o Work groups
o Departments
o The entire enterprise
· The standards and specification for each business server level that includes attributes connectivity requirements, application dependencies and characteristics, and performance characteristics, e.g. Price, Performance ratios, and capacity.
· Communication architecture: - identifies and defines the connectivity requirements for all servers and end-users to support an enterprise-wide network of data sharing. This includes standards and specification for logical and physical hardware and software capabilities for the communication network including:
o Topologies
o Protocols
o Bandwidth and capacity requirements
o Media requirements
· Operation, administration, and management architecture: - Identifies and defines requirements for managing across a multiple platform computing environment. This includes standards and specification for logical and physical capabilities relating to:
o Security
o Systems management
o Network management
o Production control
o System support
o Environmental factors
The reference model below helps in identifying what infrastructural components to consider when an infrastructure project is implemented
Figure 13: Technology Architecture Components
The following are some of the deliverables created as a result of the implementation of an Infrastructure Architecture.
· A determination of the extent that the organization’s IT supports and empowers its business functions. This includes a clear picture of the scope of the organization’s existing systems and the IT environment requires supporting these systems.
· A detailed definition of the organization’s current IT configurations and effectiveness
· A detailed business based requirements baseline to enable valid comparison of the current IT environment with the target IT environment.
· A detailed configuration model of the organization’s current hardware, software, and telecommunications
· A definition of how organization’s end users will do their work in the target IT environment that is based on business and IT requirements instead of technology
· A method for determining where data and the application that access it should be placed within the target multi-platform environment such that anyone, anywhere, given the appropriate authority, can access any application and its associated data at any time.
1.1 Security Architecture
Further to the Application architecture, Security architecture touches all levels of architectural domains; this is to ensure that the security objectives are enabled through set architecture pattern. The diagram below outlines the Security and Identity & Access Management Components and Enabling Services to be considered during overall IT implementation.
Figure 14: Security Architecture Reference Model
A centralized Security Operation ensures that data and information is accessed and updated by the right people based on the right security profiles assigned to them. A Security Framework can also be developed based on the above isolated components to form comprehensive security architecture. The following diagram covers some of the security architecture policy domains:
Figure 15: Security Architecture Policy Domains (Source Cisco)
Security policy and standards: - Organizational policies and standards that govern the system’s design, deployment, and run time. The security policy describes both what is allowed as well as not allowed in the system. Security standards should be prescriptive guidance for people building and operating systems, and should be backed by reusable services wherever practical. This is very important; it is no longer acceptable for enterprise security to exclusively function as an arbiter. Security in the enterprise needs architecture and design advocates, and backing at runtime.
Security policy and standard are not end goals in themselves, they need to be backed by a governance model that ensures they are in use, and that it is practically possible to build, deploy, and operate systems based on their intent. In practice this means that the security architecture must
define reusable security services that allow developers to not be security experts yet still
build a secure system.
Security architecture: unifying framework and reusable services that implement policy, standards, and risk management decisions. The security architecture is a strategic framework that allows the development and operations staff to align efforts, in addition the security architecture can drive platform improvements which are not possible to make at a project level. A given software development project may not be able to make a business case to purchase an XML Security Gateway for improved web services security, but at the architecture level, architects can potentially identify several projects that could leverage such a reusable service.
1 EA in play
An Enterprise Architect role can be daunting if not explicitly defined. If I had to walk in an organization as an enterprise architect, the first thing I would be interested in is the following:
· What is the organization’s core business?
· What are the organization’s values, mission and objectives?
· What is the organizations operating model and ecosystem?
· What is the organizations growth strategy & unique value proposition?
· How does IT deliver on the organization’s mission and objectives?
After understanding these questions amongst others, only then an enterprise architect start interrogating some architectural related concerns:
· Does the organization have an architecture function and what’s the structure?
· Does the organization have an architectural operating model with associated architectural KPIs and balanced scorecard?
· Does the organization subscribe to a particular architectural school of thought?
· Has the organization performed an architectural maturity assessment?
Figure 16: EA Maturity Assessment Model
· Has the organization established the current and future architectural state?
· Has the organization performed a gap analysis
· Has the organization developed a transition road map?
· Does the organization have an architectural governance model?
· Does the organization have an architectural value or benefits reporting model?
I would then use all the reference materials and guidance based on this article to fast track the adoption of enterprise architecture. These reference models below are simply guide lines to developing and managing enterprise architecture function quickly and efficiently and are iterative and not stagnant.
1.1 Enterprise Architecture Implementation Road Map
Enterprise architecture implementation roadmap sets the vision and defines the current and future domain architectures as well as the roadmap to transition the identified gap, this section also address the “What does Enterprise Architecture result in?” question.
By following a structured approach to enterprise architecture, substantial benefits can be realized based on the defined plan and according to business priorities. EA vision and capacity plus appetite for change will determine the resource and funding requirements to implement EA. Commitment and buy-in from stakeholders upfront ensures that change hurdles are managed proactively through the use of project management methodologies:
Figure 17: EA Implementation Road Map
Most of the activities in implementing enterprise architecture occur in during the definition on domain architecture “AS IS” and “TO BE” states. The following table outlines some of the high-level activities undertaken in phase two above.
Architectural Domain (TOGAF Based)
|
Activities
|
Business Architecture
|
· Develop a mutual agreement on architectural principles, vision , constraints, assumptions and requirements
· Develop baseline business architecture :
ü Drivers, goals, objectives, measurements, Organization, locations, functions, capabilities and actors and roles.
· Identify business services, processes, events and scenarios, contracts, create a Business Architecture Component (BAC) framework and tools
· Conduct formal checkpoint review of architecture
· Perform gap analysis and create report
|
Information / Data Architecture
|
· Develop Baseline Data Architecture Description
· Review and Validate Principles, Reference Models, Viewpoints, and Tools
· Define Information Classification Matrix
· Define Information distribution methods
· Select Data Architecture Building Blocks
· Conduct Formal Checkpoint Review of architecture Model and Building Blocks with Stakeholders
· Review Qualitative Criteria (e.g., performance, reliability, security, integrity)
· Complete Data High-Level Architecture
· Conduct Checkpoint/Impact Analysis
· Perform Gap Analysis and Create Report
|
Application Architecture
|
· Develop baseline applications architecture description
· Review and validate principles, reference models, viewpoints and tools
· Identify candidate application systems
· Identify integration services
· Identify application dependencies
· Conduct formal checkpoint review of architecture model and building blocks with stakeholders
· Review qualitative criteria (e.g., security, availability, performance, costs)
· Complete applications architecture landscape
· Perform gap analysis and create report
|
Technology Architecture
|
· Develop baseline technology architecture description
· Review and validate principles, reference models, viewpoints and tools
· Identify candidate technology systems that is hardware, communications and network components
· Conduct formal checkpoint review of architecture model and building blocks with stakeholders
· Review qualitative criteria (e.g., security, availability, performance, costs)
· Complete technology architecture landscape
· Perform gap analysis and create report
|
1.1 Operating Model
I believe in keeping things simple can yield the highest returns. IT concepts have been around for a number of years and enterprise architecture can leverage and streamline those concepts. System development Lifecycle is one of the IT concepts that EA can leverage. The diagram below uses SDLC concepts to optimize the operations of an enterprise architecture function:
Figure 18: EA Operating Model (Source: Microsoft)
Operating models are based on daily and mostly measurable outcomes. The above generic model is now decomposed into what I believe is an enterprise architect KPIs in-terms of managing the operating outcomes of an enterprise architecture functions:
1.1.1 Operating Model with KPIs & Benefits
It is an extension of the operating model highlighting architectural alignment to business goals with associated KPIs and benefits from managing an enterprise architecture function:
Figure 19: Expanded Operating Model (Source: Microsoft)
1.1 EA Organization Structure
Enterprise Architecture function often sits within the IT organization. There is a school of thought that it should be sitting within the office of the Chief Operations Officer or Chief Strategy Officer because it is deemed to be more strategic than an IT functions as it address business objectives and ensures that those objectives are enabled by IT. In my opinion, it really does not matter where EA sits as long as the objectives set out for EA are achieved are enough for me. I do understand why EA traditionally sits within IT, before the common acceptance of business architecture, EA always addressed IT issues and solution. Just recently has a point of view been expressed that it should move towards being a more strategic role than an IT function.
Figure 20: EA Organization Structure
1.1.1 EA Organization Structure: Roles & Responsibilities
The following table depicts the roles and responsibilities for the architectural domains shown in figure 6:
Role
|
Responsibilities
|
Chief Architect
|
· Enterprise Architecture Functional Management
· Enterprise Architecture Domains Lead
· Enterprise Architecture Policies & Standards
· Enterprise Architecture Frameworks, Tools, and Artifacts Management
· Enterprise Architecture Value / Benefits Reporting
· Architecture Governance
· Head Of the Enterprise Architecture Review Board
|
Business Architect
|
· Process Framework Design
· Process Mapping & Modelling
· Process Improvement & Re-engineering
· Business Requirements Modelling
· User Requirements Modelling
· Technical Requirements Modelling
· Business Capability Mapping
· Research & Development
· Industry Trend Watching & Analysis
· IT Strategy Development & Business Case Development
· IT Dashboards & Scorecard Management Development
· Business Drivers, Goals, Objectives Alignment & Measurement
· Business Functions Decomposition & alignment
· IT Services Qualities Management
· Business & IT Opportunities Road mapping
· Member of the Architecture Review Board
|
Data Architect
|
· Management Information Analysis & Reporting(MIS)
· Data Warehouse Management
· Metadata Management
· Data Reference Models
· Data Modeling
· Entity Relationship Management
· Data Usage & Standards
· Data Structure Management (Structured & Unstructured)
|
Information Architect
|
· Business Intelligence & Reporting
· Information Stewardship
· Master Data Management
· Information Reuse & Policies Creation
· Information Security
· Information Availability
· Information Reliability & Integrity
· Information Usefulness
· Taxonomy Definition
· Information Modelling
· Information Classification
· Content Creation (Incl. Web)
· User Experience Management
· Information on Systems Interfaces
· Information Scalability & Standards
· Information Search
· Information Monitoring
|
Application Architect
|
· Application Design Méthodologies, Standards & Processes
· Conceptual , Logical & Physical Architecture Design
· Development of Baseline & Target Architectures
· Define Services Architecture
· Define Application Security Requirements
· Integration Management
· Application Portfolio Management
· Detailed Solution Design Documentation
· Maintain Application Architecture Contracts
· Manages interactions between System Development and
· Application Support, Delivery & Maintenance
· Assessing of PoC’s & Pilots
· Functional Specifications
· Application Performance Management
· Vendor Management
· Participate in Application Testing
· Databases and Database Management Systems
· Storage Management Environment
|
Technology / Infrastructure Architect
|
· Infrastructure Standards, Policies & Procedure
· Infrastructure Reference Model
· Hardware Management Services
· Hardware Performance Management
· Middleware & Operating Systems Management Services
· Network and Desktop Management Services
· Communications Protocol Management Services
· Security Management Services & PKI and Encryption
· Management Services
· Disaster Recovery and Business Continuity
· Vendor Management
|
1.1 A day in a life of an enterprise architect
The following diagram is a representation of typical day to day in the life of an enterprise architect. This diagram assumes that the enterprise architecture function is already operational and most of the KPI’s on the table below has been agreed including other architectural resources like the EA tool and repository.
Figure 21: Typical Enterprise Architect Activity
1.1 Governance Model
The aim of the architecture governance structure is to ensure that IT is executing on business strategies and objectives. This model is multifaceted and includes the most senior members of the organization, that is, the CEO, COO and the CIO depending on how the organization is structured. It is imperative that CxO level leadership of the organization be involved in the management of the business of IT and demonstrates support and “buy-in” into the strategic intent of an enterprise architecture function. The diagram below depicts at a high-level the roles within an organization involved in the governance of enterprise architecture.
Figure 22: Enterprise Architecture Governance Model
The architecture review board agenda includes the following amongst other things:
· Assessment and need analysis of new IT products & Services
· Assessment and need analysis of decommissioning of technologies
· Assessment, advice and sign off on fit for purpose solutions,
· Detailed architectures and designs
· Review of solution compliance
· Define target state architecture
· Define IT governance framework
· Develop agendas for governance meetings
· Accountability framework
· Authorise policies
· Authorise standards, procedures and practices
· Register of statutory, regulatory and contractual obligations
· Defined value proposition for IT
· Criteria for evaluating IT performance
· Criteria for aligning IT activities with environmental sustainability objectives
· Integrated IT and business plans
· IT controls framework & report on controls
· Report on the principles of IT governance applied by all service providers
· Control framework
· Project assurance report & IT risk register
· Process‐based risk management
· Business continuity programme
1 Choosing the Right Enterprise Architecture Framework
Starts by looking at four Enterprise Architecture Frameworks that represent over 90% of the current marketplace that is, Zachman, TOGAF, FEA, and Gartner. Then create a set of 12 criteria and assigns values between 1 (very poor) and 4 (very good) for each of these criteria. Eliminate criteria that you don’t feel are important, add additional criteria that matter to your organization, and change ratings as you feel appropriate Then summarizes the criteria in the following table:
Figure 23: Choosing the EA framework (Source: Gartner)
The enterprise architect use enterprise architecture frameworks to describe how an organization’s business strategy aligns to its processes, information systems, personnel, and sub-units.
The enterprise architecture framework documents the building blocks that make up all of an organization's information assets.
These assets include all of the systems across the organization's business units. From the enterprise architect's perspective, information assets include business plans, system performance and structure, and the related processes. Enterprise architecture frameworks organize, categorize, and define relationships between these information assets.
1.1 Define Enterprise Architecture Principles
To provide a framework within which the organization can start to make conscious decisions about IT. As a guide to establishing relevant evaluation criteria, thus exerting strong influence on the selection of products or product architectures in the later stages of managing compliance to the IT Architecture. Input to assessing both existing IS/IT systems and the future strategic portfolio, for compliance with the defined architectures. These assessments will provide valuable insights into the transition activities needed to implement architecture, in support of business goals and priorities.
The Rationale statements (see below) highlight the value of the architecture to the enterprise, and therefore provide a basis for justifying architecture activities. The Implications statements (see below) provide an outline of the key tasks, resources and potential costs to the enterprise of following the principle. They also provide valuable inputs to future transition initiative and planning activities.
Figure 24: EA Principles Sample
1 Using the Right Enterprise Architecture Tools:
Remember a “Fool with a tool is still a fool”. Enterprise architecture tool needs to serve business purposes; it needs to be reused for multiple reasons and not just for process and technology modelling. Changes in the company-wide enterprise architecture map will take place and need to be
managed quickly and coherently. Manual maintenance with support of simple diagramming tools
and spreadsheets is practically impossible due to numerous and complex interdependencies. An
enterprise architecture tool provides capabilities to model, structure and visualize the enterprise
architecture contents in different ways. An enterprise architecture repository stores and
manages this enterprise architecture information, providing views, queries, reuse, access control
and versioning to a variety of different roles and projects.
Tool Questions
| |
Platform Environment
|
· Can the client software be installed on Windows 7, XP or earlier versions
· Can the client software be installed on Windows 2011R2 or earlier, Linux, Unix Servers
· Can the repository be set up using the latest versions of, Azure, SQL, and Oracle DB? Which Versions?
· Are there specific requirements or specifications to setup the repository? Which?
· Can additional licenses be added dynamically without the need to affect users PC's?
· Can the tool still operate for a period of time if the server holding the licenses fail, e.g. crashes?
· Does the tool handle extreme amounts of data e.g. millions of records?
· Does the tool operate at the same performance if there are 100 users accessing the same repository?
· Is remote access feasible and practical
· Can the tool perform several tasks at the same time? (e.g. run a report in the background)?
· Does the tool have a simultaneous update of open views without user interaction?
|
Security (User Administration)
|
· Is the user required to log on every time he uses the tool?
· Is it possible to authorize the user at the level of objects?
· Is it possible to authorize the user at the level of class properties?
· Does the tool support role based user management?
· Does the tool support check-in/check-out items of repository?
· Does the tool support read only access?
· Does the tool support management of user groups?
· Does the tool record the full history of changes to objects?
· Does the tool stamp all changes done to objects with a time-user stamp?
|
Software Distribution
|
· Is a central shared installation possible, which allows users to access the tool without local
· Installation procedures?
· Does the tool support shared installation of upgrades?
· Are upgrades possible without a system (esp. server) shutdown?
· Does the tool support shared initial installation? (I.e. can the tool be site-installed and the installation shared by users)?
· Are bug fixes distributed in the form of patches?
· Are patches freely available?
· Can patches be downloaded from the Internet?
· Do you have less than three releases a year with well before published release plans?
|
Release Management
|
· Does the tool support rollback?
· Does the tool support replication/synchronization mechanisms?
· Is it possible to replicate parts of the repository to local repositories?
|
Tool Architecture
|
· Does the tool have a client / server architecture?
· Does the tool provide a thin client?
· Does the tool provide a thick client?
· Does the tool provide standalone usage?
|
Technical & Operational Requirements
|
· Does the tool have below or average requirements on operational memory? Please define.
· Does the tool have below or average requirements on CPU? Please define.
· Does the tool have below or average requirements on external memory (disks)? Please define.
· Does the tool use a standard RDBMS? Please define.
|
Help Desk Support
|
· Can help desk support be offered in English or other languages?
· Do you provide standard escalation procedures for problem resolution?
· Is a log of all known bugs, including date of first occurrence, status and date of closure, available online for at least the last “N” months?
· Does the tool have tutorial/help on features?
· Does the tool have online documentation?
|
Training
|
· Do you have dedicated in-house product trainers?
· Do you provide training specifically for Enterprise Modellers?
· Can the training be conducted in other languages then English? Which languages?
· Do you publish regular training schedules?
· Do you provide formal training of the product?
· Is courseware available for purchase?
· Do you provide web based training /e-learning?
· Do you offer on-site trainings all over the world?
|
Professional Services
|
· Do you provide consulting services?
· Do you offer tools for (assistance with) a one-off conversion of documents from Excel, Visio, Word or
· Other format to your tool?
|
Local Support
|
· Do you offer local support world-wide or in only some regions? Please explain.
· Do you offer guaranteed reaction times?
|
Support For EA Frameworks
|
· Delivers the tool Support for Zachman, TOGAF 9, E2AF (Extended Enterprise Architecture Framework), FEAF (Federal Enterprise Architecture Framework), Gartner Framework?
· Can the tool handle references to an external custom enterprise architectural framework?
· Does the tool aid user with navigation in a custom enterprise architecture framework?
|
Repository Management
|
· Does the tool support Enterprise Architecture Diagrams?
· Does the tool have Domain Architecture Diagrams?
· Does the tool have Application Architecture Diagrams?
· Does the tool have Information Architecture Diagrams?
· Does the tool have IT Architecture Diagrams?
· Does the tool fully support Custom Type Diagrams (e. g. Management Dashboard View)?
· Does the tool support workflow?
· Does the tool have process modelling functionality i.e. process decomposition and process charts?
· Does the tool support enterprise architecture design diagrams as standard or can be customized to
· support this, with the ability to reuse applications and system interfaces from the application architecture diagrams?
· Does the tool support logical models?
· Does the tool support physical models (system level)?
· Does the tool support data flow diagrams?
· Can the user reuse all objects/definitions (metadata items)?
· Has the tool the ability to create / design network & hardware systems diagrams / models?
· Has the tool the ability to create / design communication diagrams / models?
· Has the tool the ability to support Business & IT strategy definitions?
· Has the tool the ability to store Enterprise principles and trace them to decisions?
· Has the tool the ability to support / trace risk & compliancy issues?
|
1 Benefits of EA
This section of the document is covers the question “What are the benefits of Enterprise Architecture?”
1. Single point of entry for managing change and dissemination of strategy and objective to functional business units through analysis of the business capabilities heat maps (“Top Down”).
2. Single point of entry to determining and managing all business processes and areas of improvement through a streamline business process management framework
3. Single point of entry to establish IT assets and technology portfolio for operational and financial analysis and reporting.
4. Single point of entry in managing contractors, vendors and service level agreements that is based on business services and IT Services Catalogue (“Bottom Up”)
5. A platform for managing and aligning business strategies and IT through “Top Down” & “Bottom Up” analysis and informed recommendations.
6. Reduced IT implementation costs
7. Centralized management of risks of IT projects
8. A platform to ensure that IT led projects are fit for business purposes through in-depth consultation with business and other stakeholders
9. A platform to ensure innovations activities are translated to actionable tasks and fit for business to ensure competitiveness and operational efficiency.
10. Platform to ensure that compliance to business rules and legislation are adhered by integrating them into business process and technology execution.
11. A platform to demystify technology complexities through engagement with business and solution designers, supports and service delivery units by using platforms such as Enterprise Architecture Review and Investment forums.
1 Conclusion
Enterprise architecture exists in organization whether the function is streamlined or not. It then becomes important to ensure that this function is explicitly documented and communicate to the rest of the business to achieve maximum benefits of IT investments an organization has and will embark on.
This function is a strategic role within organizations, it deals with the ever changing business and IT environment in terms of legislation, mergers and acquisitions, stuff and services downsizing, obsolete and new IT services, changing of vendors and contracts, and changing business requirements and drivers amongst other things. Enterprise architecture is also responsible for documenting and enforcing IT policies, procedure and practices. Ensuring that IT serves business objectives and also ensuring that IT led changes are deployed smoothly, timely and cost effectively.
IT is also the responsibilities of an enterprise architect to report on the performance of IT against business strategies, develop models to quantify these benefits and ensure that IT human capital is effectively utilized to meet business imperatives.
This important role requires the use of technology to capture and reuse models and other architectural artefacts that are required by different stakeholders and business ecosystems to outline business processes and other business related interaction.
The use of architectural reference models helps depict the business or organizational strategies, goals & objectives, IT landscape including hardware, human capital, business process, rules and policies, operating models and governance of IT within an organization.
There are a number of enterprise architecture frameworks in the market; it is however important to customize these frameworks and tools for organizational fit. Enterprise architect must know what will work for their business and try to avoid implementing this function by the book end to end, as this could be mundane and rip minimum benefits.
Most importantly enterprise architecture practically bridges the gap between business and IT through outlining the current state of business and the future state by developing gaps and establishing transition road maps to achieve the desired business state.
Enterprise Architecture Domains are made of building blocks that helps clarify what artefacts and deliverables will be produced. Further to artefacts, are the governance and enforcement structures to ensure that those deliverables are realized and managed properly as shown in the diagram above.
No comments:
Post a Comment