What is agility architecture?
2.WHAT IS AGILITY ARCHITECTURE?This section describe what is agility architecture from the aspect of definition, the scope, the framework, the model and the products.
The Definition
Agility Architecture enable the agility to adapt change in time of need, it is an effort to keep architecture solution simple by encapsulating repeatable complexity. Agility Architecture is achieved by learning experience of the other, the engineering of reuse and consolidation and the political process of standardization and compliance. It is considered as an horizontal architecture effort in compare to alignment architecture which is an vertical architecture effort.
2.1 Agility Architecture is Architecture in Horizontal direction
The horizontal architecture externally learn the right experience of the others and internally looks for commonality across the enterprise. It is a very different direction from the traditional vertical alignment architecture under top down or bottom up approach. The horizontal architecture is tightly couple with vertical architecture. It analyze the common primitives between the vertical solution architecture.
2.2 The scope of Agility Architecture
The agility architecture is not only about technology agility but also to business process, human resource and security as shown in the Organic EA model. It is the horizontal architecture to cut across the pillars of Enterprise Architecture. Agility architecture is not the engineering of reuse and consolidation but also the politic of standardization and compliance. In the stovepipe culture, architects are independent from standards and compliance and consider than it is a police action. However, Organic Enterprise Architecture consider that standardization and compliance is an investment to enable agility and simplicity.
3. THE HORIZONTAL AGILITY ARCHITECTURE MODEL
The horizontal agility architecture model provide an explicit model to clarify the role of reference model, reference architecture, engineering of reuse, engineering of consolidation, Standardization, Governance and Compliance.
2.4 The agility architecture framework
Organic EA suggest the agility architecture framework to incorporate the scope and the attributes of agility architecture as shown in the following figure. The agility architecture framework suggest that agility architecture applies to business, application, data, infrastructure and security with the following attributes.
. The Enterprise Architecture classification
. Reference model
. Reference architecture
. Reuse
. Consolidation
. Governance
. Compliance
3. LEARNING THE RIGHT EXPERIENCES OF THE OTHERS
Human is the only creature with the gift to learn experiences of the others, However most of people have declined to do so because of human ego. Agility architecture is effort to explore the human potential in learn experience of the other and overcome the difficulty in establishing agility. Human is the only creature with the capability to learn experience of the others but it is also human nature to decline the gift of leaning experience of the others. Learning experiences of others save the effort to reinvent wheel but it also have the risk to learn the wrong experience by comparing apple to orange. The Agility Architecture learning experience of the others with reference model to classify their architecture and adopt the right reference architecture to save redundant effort.
The risk of learning experience of others is comparing apple to orange. The Agility architecture learn the right experience of others by classifying the organization's holistic architecture into common recognized architecture class based on reference model classification and learn experience from different reference architecture based on the right architecture classification as shown in the following figure.
3.1 Reference Model serve as the architecture taxonomy to establish the common architecture communication platform and keep architect on the same page and mitigate the risk of learning from the wrong experience. It also can be used to establish service level agreement and Enterprise architecture mark up language.
3.2 Reference Architecture is the collection of experiences as an architecture template for a special line of business which has great value for the architect to provide agile and simple architecture solution.
4. THE ENGINEERING OF REUSE AND CONSOLIDATION
Organic EA enable the agility to adapt change by establishing the infrastructure and common building blocks which change gradually. By saying the world change constantly, it does not means that it is futile to plan ahead because there are thing that change rapidly and there are things that change gradually. The strategy to adapt change is to accommodate rapid change with thing that change gradually. The value of planning dose not only serve as an step by step to follow but also enable the agility to adapt change. The level of agility and simplicity increase with the level of common foundation and reuse as shown in the following figure. With the build up of common foundation and building blocks, business owner can optimize their local architecture solution based on their business without special resources and in time of use.
The following figure describe the engineering of reuse and consolidation. The engineering of reuse and consolidation may sounds redundant but they have very different engineering property. The major difference between engineering of reuse and the engineering of consolidation is that the engineering of reuse is driven by patterns and the engineering of consolidation is driven by workload and performance. The engineering of consolidation is the architecture effort of consolidation design to share common resources such as service oriented architecture and actualization effort. The model of reuse and consolidation adopt the same architecture layers from the tradition EA model. It consist of the business architecture, application architecture, data architecture and technology architecture. Business architecture describes the enterprise missions, functions, information, people, location and workload.; The data architecture identifies the enterprise information assets and structure underline the business architecture; The application architecture describes how application systems support the business and data architecture. It automate the business process which must be re engineered before automation; The technology architecture which include the application , integration, data, collaboration, network and platform technologies.
5. THE POLITIC OF GOVERNANCE AND COMPLIANCE
Agility architecture is not only an engineering effort but also a political activity to earn buy-in from stakeholders.
Governance and compliance is the investment to earn agility
Stovepipe architects may consider that governance and compliance are the policing act to jeopardize their creativity, Enterprise Architects consider that Governance and compliance is the investment to earn agility and simplicity. Although it appears to be a limitation that the community have to follow standards and subject to consolidation, but consider the benefit of reuse and consolidation, governance and compliance is not really a burden, it is a remedy to overcome the challenge of stovepipe system.
Governance and Compliance constitute the EA operation
Governance and compliance are the mechanism to establish the common foundation and building blocks. The continue operation of governance and compliance serve as the engine to build up the common foundation and building blocks. An enterprise must optimize their governance structure and processes properly to establish common foundation and building blocks efficiently in avoidance of unnecessary burden to the stakeholders.
5.1 The governance process with participation from stakeholders is similar to the legislative processes in a government. The standards and regulations become the law to be complied in the IT community. Stakeholder participation through the representations in the architecture standard review board or the stakeholder steering committees and the architecture standards review board to ratify the standards and regulations recommend by the architect. Stakeholders are also entitled to initiate change requests through their representatives to modify the standards and regulations.
5.2 The compliance process review the architecture compliance to the standards, regulations and the sharing and reuse of common IT resources to resolve the issue of stove pipe systems. In PEA approach, business owners initiate application system to automate locally optimized business processes based on there need rather than centrally design by the enterprise architects. The compliance review processes assure not only the quality of the application systems but also the sharing and reuse of common IT resources.
5.3 Stakeholder buy-in via political process. In the stovepipe culture, where reuse and sharing is not a concern, stakeholders are not subject to the constrain of interoperability. In EA, to overcome the challenge of stovepipe system, stakeholder have to invest on standardization for interoperability. EA is accomplished via the political process of buy-in rather a command and control process to impose standards. In the political processes, the law makers elected by people establish the law and the government enforce the law accordingly. In the same token, the EA standards and regulations must also been established by stakeholders rather than by the EA professionals. Establishing EA standards and regulations via consensus from stakeholder empower the legitimacy to enforce the EA standards and regulations.
^ TOP
The Agility Architecture Model describe the approach
The Agility Architectrue model is a twin pyramid model as shown in the following figure rather than the familiar single pyramid in the traditional EA apporach. It take both logical and physical architecture into account.
The traditional EA models is evovled from applicaiton development concept which can lead to a larger stovepipe system. The
twin EA model explicitly incorporate the engineering of reuse to learn experience of others.
The Agility Architecture model is a twin based on The following research suggest that EA model, different from application development model, is a twin rather than the traditional pyramid which is derived from application development concept. From the aspect of EA definition, Zachman have suggested the the product definition and enterprise definition. From the aspect of IT architecture, there are two parts of physical and logical architecture. From the relation between the EA definition and IT architecture, the business logic drive the logical architecture and the performance requirements drive the physical architecture. Based on these analysis, LEA suggest the twin EA model to consist of the engineering of reuse and engineering of sharing
7.2 EA is defined by product definition and enterprise definition
EA by definition have two part, the product definition and enterprise definition. Enterprise definition distinguish EA from application development. John Zachman explained the difference between enterprise architecture and application development in the Enterprise Architecture Artifact Vs Application Development Artifact [10] and defined the “ Product Definition” and “Enterprise Definition” in The Framework for enterprise architecture : Background, Description and Utility . He stated :
“ The older disciplines of Architecture and Manufacturing have accumulated considerable bodies of product knowledge through disciplined management of the “product definition” design artifacts. This has enormous increases in product sophistication and the ability to manage high rates of product change over time. Similarly, disciplined production and management of “Enterprise definition “ (i.e. the set of models identified in the Framework of Enterprise Architecture ) should provide for an accumulation of a body of Enterprise knowledge to facilitate enormous increase in Enterprise sophistication and accommodation of high rates of Enterprise change over time.”
Although Zachman define the “product definition” as the WHAT, HOW, WHERE columns and the “Enterprise definition” in the WHO, WHEN, WHY columns in the framework. LEA would like to suggest that that the product definition to be “ Why, What, How” and the enterprise definition to be “ Who, Where and When” where The product definition describe the business logic with the need (Why), The information substance (What) and The processes (How). and enterprise definition describe the enterprise with the people (Who) , the location (Where) and the workload peak time (When).
7.3 IT architecture contains the logical architecture and physical architecture
IT Architecture contains logical architecture and physical architecture. The U.S. Department of Transportation National ITS architecture define the logical and physical architecture as following :
The Logical Architecture defines the Processes (the activities and functions) that are required to provide the required User Services. Many different Processes must work together and share information to provide a User Service. The Processes can be implemented via software, hardware, or firmware. The Logical Architecture is independent of technologies and implementations.
The Physical Architecture forms a high-level structure around the processes and data flows in the Logical Architecture. The physical architecture defines the Physical Entities (Subsystems and Terminators) that make up an intelligent transportation system. It defines the Architecture Flows that connect the various Subsystems and Terminators into an integrated system. 7.5 The engineering of reuse and engineering of sharing
The LEA suggest a twin EA model, as showing in the following figure, instead of the traditional pyramid model. It is a model to convey the two parts characteristics in EA as described in the previous paragraphs. The twin EA model incorporate the concept of learning from the others experience rather by adopting established patterns rather than conducting pattern recognition in a waterfall approach.
The LEA model convey the concept that EA is the engineering of reuse and sharing rather then an enterprise application system engineering project. Fail to recognize that EA is the engineering of reuse and sharing has been the major obstacle of EA evolution. From, the traditional EA model, there is very little difference between application development and enterprise architecture. As a result, most of the application system engineering trained IT professional are unable to distinguish EA from application development and considered that EA as a enterprise wide application architecture effort. It is a complicate effort to design the enterprise wide application systems because application design requires all the detail and turn out to be an overwhelming and complicate effort. After the hard work to design enterprise wide application systems, the architect find out that buy-in from the stakeholder is the real challenge.
The engineering of sharing and the engineering of reuse may sounds redundant but they have very different engineering property. For example : We sharing a pie but do not reuse a pie. The criteria to share a pie is based on the number of people and how hungry they are. The criteria to reuse a pie is learn from experience by obtaining a copy of recipe. The major difference between engineering of reuse and the engineering of sharing is that the engineering of reuse is driven by patterns and the engineering of sharing is driven by workload and performance.
The engineering of reuse is to identify the common standard and building blocks. Every EA project has started with technical reference model which is the EA 101. The effort of TRM to identify technologies and establish standards is fundamental part for the engineering of reuse. The EA project initially use TRM to establish technology standard profile for the purpose of interoperablility and reuse and gradually extended the concept beyond TRM to include the business, performance, application service and data . The engineering of reuse is based on pattern analysis. The concept of reuse has also evolved from learn from your experience to learning the experience from the others via pattern adoption instead of pattern recognition.
The engineering of sharing is the architecture effort of consolidation design to share common resources. A pile of bricks does not make a building., a list of standards and building blocks from the engineering of reuse do not constitute an architecture either. The engineering of reuse learns the experience from the others and the engineering of sharing must be designed based on the enterprise definition of workload and performance requirements over the mission demand and geographical distribution.
The LEA model establish the common foundation and building blocks to enable the agility of automation solution. The automation systems are developed based on the business owner’s need rather than impose the solution base on the central planned architecture design. LEA as the effort to provide the common foundation and building blocks has greatly reduce the complexity of EA so that it qualify as the Light Enterprise Architecture.
The twin EA model assume the same architecture layers from the tradition EA model. It consist of the business architecture, application architecture, data architecture and technology architecture. Business architecture describes the enterprise missions, functions, information, people, location and workload.; The data architecture identifies the enterprise information assets and structure underline the business architecture; The application architecture describes how application systems support the business and data architecture. It automate the business process which must be reengineered before automation; The technology architecture which include the application , integration, data, collaboration, network and platform technologies.
7.4 Business logic drive the logical architecture and workload drives the physical architecture
The relation between the EA definition and the IT solution is that the business logic drive the logical architecture and the workload and performance drive the physical architecture as Mary Konx of Gartner Group [] says “Logical architecture are the principles that guide the design of an enterprise data and application logic assets and the messages that pass among them, regardless of whether these assets are based on current systems, purchased application packages, outsourced services or in-house development. Logical architecture transcend immediate application functionality future states of its IT design. Logical architectures differ from physical architectures, Logical design is a function of business information requirements; physical design is a function of performance issue. “
The following example further illustrate the concept that business logic drives the logical architecture and workload and performance drives the physical architecture. In an open system environment, a PC can support both simple and complication software system because it is not a function of business logic. However, it requires a mainframe computer to support the demand of an enterprise because the physical architecture is a function of workload and performance requirement.
7.5 The engineering of reuse and engineering of sharing
The LEA suggest a twin EA model, as showing in the following figure, instead of the traditional pyramid model. It is a model to convey the two parts characteristics in EA as described in the previous paragraphs. The twin EA model incorporate the concept of learning from the others experience rather by adopting established patterns rather than conducting pattern recognition in a waterfall approach.
The LEA model convey the concept that EA is the engineering of reuse and sharing rather then an enterprise application system engineering project. Fail to recognize that EA is the engineering of reuse and sharing has been the major obstacle of EA evolution. From, the traditional EA model, there is very little difference between application development and enterprise architecture. As a result, most of the application system engineering trained IT professional are unable to distinguish EA from application development and considered that EA as a enterprise wide application architecture effort. It is a complicate effort to design the enterprise wide application systems because application design requires all the detail and turn out to be an overwhelming and complicate effort. After the hard work to design enterprise wide application systems, the architect find out that buy-in from the stakeholder is the real challenge.
The engineering of sharing and the engineering of reuse may sounds redundant but they have very different engineering property. For example : We sharing a pie but do not reuse a pie. The criteria to share a pie is based on the number of people and how hungry they are. The criteria to reuse a pie is learn from experience by obtaining a copy of recipe. The major difference between engineering of reuse and the engineering of sharing is that the engineering of reuse is driven by patterns and the engineering of sharing is driven by workload and performance.
The engineering of reuse is to identify the common standard and building blocks. Every EA project has started with technical reference model which is the EA 101. The effort of TRM to identify technologies and establish standards is fundamental part for the engineering of reuse. The EA project initially use TRM to establish technology standard profile for the purpose of interoperablility and reuse and gradually extended the concept beyond TRM to include the business, performance, application service and data . The engineering of reuse is based on pattern analysis. The concept of reuse has also evolved from learn from your experience to learning the experience from the others via pattern adoption instead of pattern recognition.
The engineering of sharing is the architecture effort of consolidation design to share common resources. A pile of bricks does not make a building., a list of standards and building blocks from the engineering of reuse do not constitute an architecture either. The engineering of reuse learns the experience from the others and the engineering of sharing must be designed based on the enterprise definition of workload and performance requirements over the mission demand and geographical distribution.
The LEA model establish the common foundation and building blocks to enable the agility of automation solution. The automation systems are developed based on the business owner’s need rather than impose the solution base on the central planned architecture design. LEA as the effort to provide the common foundation and building blocks has greatly reduce the complexity of EA so that it qualify as the Light Enterprise Architecture.
The twin EA model assume the same architecture layers from the tradition EA model. It consist of the business architecture, application architecture, data architecture and technology architecture. Business architecture describes the enterprise missions, functions, information, people, location and workload.; The data architecture identifies the enterprise information assets and structure underline the business architecture; The application architecture describes how application systems support the business and data architecture. It automate the business process which must be reengineered before automation; The technology architecture which include the application , integration, data, collaboration, network and platform technologies.
Read More → ^ TOP