Talking about Enterprise Architecture

Nuestro buen amigo Juan Carlos Olamendy ha escrito un interesante articulo, aqui el detalle:

By JC Olamendy

Enterprise Architecture (EA) is the description of the enterprise from a systemic perspective. It enables to specify the main enterprise components, its relationship and how they expose their functionality and properties to the external environment. This disciple has emerged in the need to align the business process with the technologies in order to enable have an acceptable return on investment with information technologies because of the increase of system complexity and poor business alignment. In this article, I will talk about the principles of EA as well as the common methodologies needed to develop the overall architectural vision of the organization.

Using EA, you can understand the business goals, business process, roles, organization structures and behaviors, business information and the supporting information system and its underlying infrastructure. And it’s the means for effective management and exploitation of information systems in order to make the business successful and more competitive.

Several methods and frameworks have come in these days, and the commonly used are:

• Zachman Framework for EA. It’s a taxonomy for organizing architectural artifacts,
• The Open Group Architecture Framework (TOGAF). It’s a process for creating EA,
• Federal Enterprise Architecture.

Although you can find several EA frameworks, all of them have these similarities: four key domains such as Business Architecture, Applications Architecture, Data Architecture and Technology Architecture.

The components comprise each key domain are:

• For the Business Architecture:

o Strategy maps, goals, policies, operating model,

o Functional decomposition, business capabilities and organization models,

o Business process, workflow, business rules,

o Suppliers, clients, products, services.

• For the Information Architecture:

o Information and data models to express the information architectures: conceptual, logical and physical

o Master Data Management models, methodology, best practices,

o Description of the enterprise data elements (Metadata Management),

o Business Intelligence and reporting,

o Data Integration. Operational Data Store, Data Marts, and Data Warehouse,

o Data Life Cycle Management to govern how to create, classify, update, reuse, distribute and archive data and information.

• For the Applications Architecture:

o Applications inventory and diagrams,

o Interfaces between applications,

o Service-Oriented Architecture,

o Applications portfolio management,

o Applications relationship and communications.

• For the Technology Architecture:

o Infrastructure supporting the applications. Hardware, software, hosting environment such as servers, data centers and computer rooms,

o Execution environment: operating systems, application servers, database management systems, security environments, IT monitoring environment,

o Connectivity: LAN, WAN, Internet access,

o Links with parties outside of the organization: Intranet, Extranet, Internet, eCommerce, EDI.

Let’s start talking about Zachman Framework for EA. This framework provides a formal and highly structured way of viewing and defining an enterprise. It’s remarkable to say that it isn’t a methodology because it lacks specific methods and processes for managing the information that it describes. It’s a taxonomy for organizing architectural artifacts taking into account different targets (for example, business owner and builder).

This framework consists of a two dimensional classification matrix based on the intersection of the columns with the aspects of the architecture (What, Where, When, Why, Who, How) and the rows with the definition of the type of stakeholders, objectives and scope (see Figure 1).

Figure 1

The basic idea underlying Zachman framework is that the same complex thing can be described using different level of abstractions and different perspectives. For example, for the owner’s perspective, the data means entities such as Customers and Products and their properties and relationship. From the builder’s perspective, the data means tables, queries, indexes, views, data files, transaction log files, etc. A realization of the Zachman Framework can be seen in the Figure 2.

Figure 2

There are several aspects to consider when realizing the framework as shown in the Figure 2. Every architectural artifact should be in exactly one cell. A cell is considered complete when it contains sufficient artifacts to fully define the system for one specific stakeholder. And finally, cells in columns should be related to each other. For example, while the business owner thinks differently about data from the database administrator, there should be some relationship between these perspectives. If you can’t find a trace from the data in the business owner perspective down to the data administration, then you can conclude that some business needs are not covered by the data architecture. On the other hand, if you can’t find a trace from the data administration to the business owner, then you can conclude that there is unnecessary information in the data architecture.

Now, I will talk about TOGAF. This method was developed by the members of the Open Group consortium, and TOGAF stands for The Open Group Architecture Framework. TOGAF is a method which has four modeling levels: Business, Application, Data and Technology. The business architecture defines the business goals and strategy, products and services, governance, organization and key business process. The application architecture provides a blueprint for the applications and systems supporting the business processes. The data architecture describes the data assets, its organization and the associated data management systems. The technical architecture describes the hardware, platforms and network infrastructure.

The key component of TOGAF is the Architecture Development Method (ADM) which is a process providing guidance in order to analyze and implement a holistic vision of the enterprise. ADM is a generic methodology, so it doesn’t define a particular set of deliverables. You can even use ADM as the process to design the EA along with Zachman framework to classify and describe the artifacts in EA. The following diagram represents the ADM as an iterative and cyclic process (see Figure 3).

Figure 3

Another important component of TOGAF is the Enterprise Continuum which is a repository of artifacts involved in the design and implementation of your system such as models, patterns and other architectural work.

Now let’s describe the ADM. The preliminary phase is where we talk about the objectives, the scope, concepts, assumptions, methods and tools for EA to key stakeholders (who will be involved in, or benefit from) and their responsibilities.

The architecture vision (phase A) is where we understand the business principles, goals and strategic drivers for the organization to clarify the purposes, so a baseline for the EA (as-is) and target environment (to-be) is established. It’s defined the key business requirements, business constraints and the strategies to address the architecture effort as well as to assess the benefits and impacts of the EA. In this phase, you may use a business scenario where you would identify in a workshop what are the business problems, business requirements and identify potential business solutions. The EA team will collaborate with the business team to understand and scope the needs.

In the practice, this phase begins with a Request for Architecture Work (RAW) document including the business reasons, budget and personnel information. As soon as the RAW document is ready, then the TOGAF consultant will define the project scope, identify constraints, document business needs and establish both the baseline (as-is) architecture and the target (to-be) architecture. The output of this phase is the Statement of Architecture Work (SAW) document with the architectural vision (high-level definitions of business, technology, data and application architectures for the baseline and target EA).

The business architecture phase (phase B) describes the product and service strategy, the organizational chart, business function and processes, key business process, geographic aspects to support business goals by using tools such as business process and use-case models. You can also perform gap analysis of your baseline and target architecture.

In the practices, the input for this phase is the Statement of Architecture Work (SAW). In this phase, the TOGAF consultant will create a detailed baseline and target business architecture and perform a gap analysis between them as the output for this phase. The TOGAF consultant works closely with business people.

The information system architecture phase (phase C) is to analyze and specify both the data and application domains. The data architecture phase specifies the key business entities, its processing and flow of information to support the business processes. It’s remarkable to say that this phase is not concerned with database design (not to design logical and physical data model). The application architecture defines the key application systems to support business process and their underlying relationship. It’s remarkable to say that this phase is not concerned with systems design but a logical group of capabilities to manage data entities and support business functions in order to do a business gap analysis.

In the practices, the TOGAF consultant will create a detailed baseline and target data and applications architecture and perform a gap analysis between them. The TOGAF consultant works closely with CIOs, software architects, integration architects and information architects.

The technology architecture phase (phase D) defines the hardware, platforms and network infrastructure to support the business and information architectures in phases B and C.

The opportunities and solutions phase (phase E) evaluate and select the best implementation strategy. You look at the building blocks and then determine what you can build, buy or re-use, as well as the underlying projects to be undertaken to move from the current state to the target state (part of the architecture vision). This phase also considers whether or not existing systems could be replaced all at once. Assess the dependencies, costs and benefits of several projects in order to minimize the overall impact on enterprise operations.

The migration planning phase (phase F) describes how to get to the target EA part of the vision by describing the implementation projects in priority order. Each project provides a detailed implementation plan as well as the migration plan.

The implementation governance phase (phase G) specifies the architecture contract to govern the overall implementation and deployment process in order to ensure conformance. In this phase, we formulate the recommendations for each implementation project by participating in assessment of the solutions consistent with the global business strategies, re-analyzing business practices as well as recommending architectural styles, application design, design patterns, best practices, development framework and tools. We can identify if there are any issues between the architecture and implementation organization. In this phase, we perform appropriate governance functions while the solution is being implemented and deployed such as IT Service Management, Project Management, Risk Management, Security Management and Audit Management. This will ensure conformance with defined architecture by the implementation projects by reviewing ongoing implementation and the architecture building blocks.

The architecture change management phase (phase H) enables to establish a change management process for new EA baseline. This process provides the continuous monitoring to determine if a new architecture evolution cycle needs to initiate. In this phase, you request for change and determine how it will proceed. You can find changes such as improvement of the business process, new standards initiative, and new technology adoption , etc. Some changes require going to the previous phases.

The second part of TOGAF is the Enterprise Continuum which provides a repository of models, patterns and other artifacts you create to interact with ADM. Conceptually, Enterprise Continuum is made of the Architecture Continuum (models, patterns and so on) and Solutions Continuum consisting of the guidelines of using the models and patterns to achieve the Architecture Continuum. It goes from the general to the specific.

The Open Group also manages the IT Architect Certification program (ITAC) which provides a way for architects to obtain an industry standard certification.

Next part of this article is concerned to talk about how Service-Oriented Architecture (SOA) and Enterprise Architecture (EA) work together.

Let’s start talking about the definition of SOA. Service-Oriented Architecture is defined as:

• According to the W3C’s definition: “A set of components which can be invoked, and whose interface description can be published and discovered”,
• According to IBM’s definition: “It’s an enterprise-scale IT architecture linking resources on demand. These resources are represented as services which are consumed by clients and are composed to fulfill business needs”,
• According to my own definition: “It’s an architectural style represented by three key building blocks: services, clients and the discovery repository. The relationship between these building blocks is as follows: services exposed its functionality as services to be aligned with business functions, the description of these services (service metadata) is registered in common repository according to a given taxonomy in order to be searchable and to enforce design and runtime rules, and finally the clients who finds the services in the common repository and consume these services following the established design and runtime rules. The services can be integrated and composed in large applications to fulfill business needs”.

In order to map the principles and architecture domains (scope) of EA and SOA, it’s remarkable to say that SOA domains are a subset of the EA domains. For example, SOA is not concerned with the business architecture (EA concerns); instead SOA uses the outcome of the business architecture (business processes and other artifacts) as the input to identify services aligned with business needs. The bottom line is that SOA is concerned with services (to fulfill business needs) and the components to support these services and EA is concerned not only with SOA artifacts but with other building blocks which are part of the whole enterprise (from the systemic point of view).

Let’s analyze the difference and similarities between EA and SOA.

EA and SOA both:

• Address similar architecture domains,
• Are intended to close align IT with business,
• Use input based on business objectives,
• Require similar strategies and planning activities to achieve their goals.

The main differences between EA and SOA are:

• EA focuses on defining business components, while SOA focuses on business services,
• EA focuses on enterprise applications while SOA focuses on service modeling,
• EA focuses on the enterprise level infrastructure (servers, database, etc) while SOA focuses on the infrastructure to support services such as Enterprise Service Bus (ESB),
• EA focuses on Enterprise Application Integration based on different mechanisms such as point-point base, ESB-based, message-based, file-base integration methods. SOA provides the Service-oriented integration approach.

Next table will summarize the different architecture domains covered by SOA and EA (see Table 1).

Table 1

Another common aspect in EA and SOA is the governance: EA implementation governance (phase G) and SOA governance.

Architecture governance is the practice by which the EA are managed and controlled at the enterprise level. IT governance is the practice to direct control the enterprise IT assets in order to achieve the goals. SOA governance is the practice by which we manage and control the services in SOA solutions. SOA governance can be seen as a subset of IT governance which is a subset of architecture governance.

The similarities between EA governance and SOA governance can be resumed in managed and control which means:

• Both require executive committee oversight,
• Both require a review committee,
• Both address issues at the enterprise level,
• Both ensure that the business and IT assets are correctly aligned

And the main differences between EA governance and SOA governance are:

• SOA governance is a tactical view of the enterprise while EA governance is a strategic view
• SOA governance requires more measurement to ensure the return of investment which it’s not a concern in EA governance.

And finally, let’s talk about the relationship between enterprise and software architectures. While enterprise architecture defines the abstraction of an enterprise by separating two interdependent domains: the business and IT systems architectural domains; then the software architecture defines the abstraction of IT systems.

Software architecture consists of the representations of system’s components, its relationship and the key properties and services exposed to the world. One common method to represent the software architecture is 4+1 Architectural View Model designed by Philippe Kruchten. This method comprises of views: logical, process, development, physical and use case or scenario views. The logical view is concerned with functionality that the system provides using UML diagrams to mainly represent this view. The Class, Sequence, Activity diagrams describe this view. The development view illustrates the system from the builders’ point of view. The Component diagram in UML describes this view. The process view deals with dynamic aspects of the system explaining the runtime behavior, the main processes and how they communicate each other. The Activity diagram in UML describes this view. The physical view is concerned with the topology of software components on the physical layer as well as the connections between them. The Deployment diagram in UML describes this view. And finally, the scenario view is concerned with use cases describing the sequence of interactions between objects and actors of the system. They are also used to identify architectural elements and to validate the architecture design. The Use Case diagram in UML describes this view.

Conclusion

In this article, I have talked about the principles of EA as well as the common methodologies needed to develop the overall architectural vision of the organization.

Ver el articulo aqui.

Saludos

Fernando García Loera (Community Program Manager – Latin America Region)

Que es un MVP? Tips para ser MVP