The Alignment Architecture - EA vertically
3. WHAT IS ALIGNMENT ARCHITECTURE
The alignment architecture facilitate the business community on how to take advantage of engineering discipline and technology evolution. It is not an architecture approach for the engineering community on how to design an enterprise wide solution architecture as an large project.
Definition
The Alignment architecture facilitate the business community on taking advantage of technology evolution. It is an orderly arrangement between the parts of business need and the parts of technology services. The Alignment Architecture is a vertical architecture approach to align application, data and technology solutions to the holistic business architecture.
3.1 Align to the holistic business architecture The Alignment architecture aligns to the holistic business architecture to constitute and enterprise alignment architecture. To be practical and manageable, The enterprise alignment architecture should be wide and thin.
3.2 Facilitate business community in taking advantage of technology evolution Alignment architecture provide a great value to serve as the bridge between business community and engineering community. EA as an enterprise wide solution architecture is an opportunity and challenge to architecture but have limit value to the business community. It contribute to the lack of buy-in from business community.
3.3 Alignment architecture serve both the business community and the technology community. It should be intuitive and comprehensive to the business managers. The Alignment architecture facilitate the business community on how to leverage on engineering solution such as business process engineering, human resources engineering, technology engineering and security engineering to win the edge of competition.
3.4 Alignment architecture does not requires significant initial investment The Alignment architecture does not requires significant time and resources because it is notional instead of an target enterprise architecture blueprint.
4. ALIGNMENT ARCHITECTURE MODEL AND FRAMEWORK
4.1 Alignment Architecture model
Alignment Architecture adopt NIT Enterprise Architecture model to align technology with business need as shown in the following figure. It was developed by the National Institute of Standards and Technology (NIST) in 1989, became in the 1990s widely accepted and promoted within the U.S. federal government as an Enterprise Architecture management tool. This model is basically a top down alignment architecture in vertical direction.
4.2 ALIGNMENT ARCHITECTURE FRAMEWORK
Alignment Architecture framework (Business/Technology) is vertical architecture to align solution to business. The alignment architecture is considerd as the notional Target architecture which serve as the master plan. It consist of the business process alignment, application alignment, data alignment, security alignment and technology alignment.
5. THE ALIGNMENT ARCHITECTURE APPROACH
The alignment architecture adopt the most familiar EA practice to identify the As-is environment and the Target alignment environment as shown on the Alignment Architecture model. However, Organic EA do not recommend to conduct gap analysis and plan for transtion at enterprise level.
5.1 A human centric alignment architecture
To facilitate the business community, the organic EA take an enterprise mapping approach to map automation service on the holistic business architecture map described in the Holistic Business Architecture section.
5.2 The As-is Alignment Architecture
The As-is alignment architecture identify the automation tools used by the business community in business operation. It describe how business community use the automation and other solution to achiever their goal rather than documenting the detail of automation systems. The first generation EA refer this effort to document as-is and frequently evolved to become an inventory and asset management exercise. Many EA projects have bog down at the stage to document as-is without the opportunity to design for the future.
.As-is Application Alignment Architecture - Defines what applications are in place to manage the data and support the business functions (i.e., application models).
.As-is Data Alignment Architecture - Defines what data is in place to support the business (i.e., data models).
. As-is Technology Alignment Architecture - Defines what supporting technology is in place to provide an environment for applications that manage the data and support the business functions (i.e., technology models).
5.3 The Target Alignment Architecture
The target alignment architecture serve as the enterprise master plan. It facilitate the business community to take advantage of technology evolution by aligning automation systems to support business operation. A Target Alignment Architecture should be intuitive and comprehensive to the business community.
. Target Applications alignment Architecture - Defines the applications needed to manage the data and support the business functions (i.e., applications models).
. Target Data Alignment Architecture - Defines the data needed to support the business (i.e., data models).
. Target Technology alignment Architecture - Defines the supporting technology needed to provide an environment for applications that manage the data and support the business functions
5.4 Alignment Architecture not for transition plan
The high level alignment architecture is not recommended for making transition plan by analyzing the gap between the As-is and Target Alignment. The light EA approach, suggest to plan for transition architecture at the segment architecture level rather than at the enterprise level because most of EA transition plan at the enterprise level has been overwhelming and not practical.
6. ALIGNMENT ARCHITECTURE IS NOT ONLY ABOUT TECHNOLOGY
An organization does not relies on technology solution but also on alignment of business processes, human resources and security as shown in the Organic EA model
. The Business process alignment architecture
. The Human resoruces allignment architecture.
. Technology
. The Security Alignment
^ TOP
The initial EA & Segment Architecture
Initial EA is the notional target archtiecture
Initial EA is not execuatble
Enterprise Target Architecture is the master plan rather than the heavy duty architecture design blueprint. In the analogy of City planning, the target architecture is similar to the master city plan and the city is developed incrementally by different segment in the city. For example : The city of Washington DC was planed Major Pierre Charles L'Enfant on the year of 1800, it has been the master plan of Washington DC since then. Instead of taking Nero’s approach to design and build the city in a “Big Bang” approach, the city of Washington DC is developed in a segment architecture approach base on business need.
The purpose is to deliver EA value from the very beginning rather than a waterfall approach only to see the result at the very end. It also relive the EA project from the burden of making significant effort to design the entire enterprise and just to see it become obsolete due to rapid technology evolution. For example of this is the capital city of Kabul, Afghanistan,
Why initial EA?
Traditional EA use a "Big Bang" approach
Many EA projects , under the name of “Architecting the Enterprise”, made significant initial investment to design their Target Enterprise Architecture in a “Big Bang ” approach as if it is a large application system. Many EA experts, failed to make transition from application development to EA themselves, like to use the analogy of architecture blueprint to explain what is EA. They locked up their best architects for couple year to design the enterprise as if designing an aircraft carrier only to find that architecture buy-in from stakeholder is not guaranteed and the architecture design become obsolete due to rapid technology evolution.
In this very waterfall approach, the enterprise will not be able to benefit for EA until it is implemented in the same way that the aircraft carrier can not be launched for services until it is delivered. The fact is that enterprise can hold up their operation to wait for the great pumpkin of EA to come.
It is futile for EA in a command and control approach
It is futile to design a central planned blueprint in a command and control approach to impose enterprise architecture in a militaristic/totalitarian style. EA is all about people and business processes in an enterprise subject to local business reengineering based on geographical location and culture difference. The command and control approach do not serve well in a people community. The experience of central planned economy in socialism country by the social architects has very limited success. To the IT community, EA is a notion of command and control and they would like to pay for EA to go away.
It is futile because the central planed EA approach does not provide values in time for practical use. The traditional EA approach requires significant investment of time and resource to design the entire architecture blueprint. In many EA projects, the enterprise architects simply walk way to design the most efficient architecture for a long time and resurface with a architecture blueprint without stakeholder participation. The business owners can not afford to wait for a long time due to their immediate of automation .. The great promise from architecture is only a promise without practical value. They have no choice but develop the stovepipe systems.
It is futile because the central planned EA approach is lack of architecture buy-in from the stakeholders. After the hard work of design the entire architecture blueprint, the enterprise architects find out that architecture buy-in from the stakeholders is actually more difficult. The central planned EA approach does not provide enough value to earn the architecture buy-in from stakeholders. It overlook the fact that EA is all about people [] and the fact that the central planned architecture does not support the stakeholders need due to that business processes subject local business process reengineering.
EA is all about people, it is the engineering of reuse and sharing among many different business owners. In the people oriented civil community, there are always many difference due to human nature and culture. In the human society, central planed architecture in a command and control approach have very limited success for example : the experiment of Marxism and communism country in a central planned command and control approach have limited success.
Business processes subject to local business reengineering. Enterprise architecture is not an factory automation effort where business process can be optimism under the factory environment in a mechanical process. The central planned architecture approach is based on the assumption of optimized business process design and standardization as if it is in a factory automation environment. It overlook the fact that business processes subject to local business process reengineering in an enterprise based on geographical distribution and culture difference in the human community. For example : The best way for you to come to work is not necessary the best way for me because of different geographical location and culture.
2. Enterprise Target Architecture is a high level master plan
At the initial stage of EA, in instead making heavy investment to design the entire enterprise blueprint, it is more practical to establish the enterprise master plan which is similar to a master plan in city planning. The master target architecture plan do not requires significant effort of time and resources. The EA Target Architecture plan is developed based on the enterprise mission and direction and serve as the guide and the framework for the enterprise. LEA is a continuous architecture effort to elaborate the target architecture design . It can be for the development for a new segment or the modernization of an old segment.
2.1 Enterprise Target Architecture must be holistic
The Enterprise Target Architecture plan must be holistic to cover every aspect of Enterprise Architecture at the high level. LEA suggest to use enterprise architecture framework as to assure that enterprise target architecture is comprehensive to describe the high level architecture in each area
2.2 Enterprise Target Architecture describe the connectivity
The enterprise target architecture must describe the relation and connectivity between architecture components in different areas of the framework. The relation and connectivity serve as the context to relate and integrate segment architecture.
6.1 Initial EA
Initial EA is the effort to establish the holistic view of the enterprise to establish high level and notional architecture principle. Enterprise see the return on EA rather quickly from the initial EA with significant investment of time and resources.
Unlike the big-bang approach in EA 1.0 which requires significant time and resources, the Initial EA does not requires exhausted effort to design and plan for transition.
The initial EA do not requires significant time and resource. It is the effort to establish the EA governance , render the big picture, know the enterprise and align the notional and high level target direction. It does not include the time consuming gap analysis and transition plan because the target architecture is notional and high level.
6.2 Continuous EA by Segment Architecture
EA is implemented via segment architecture in an incremental and continuous manner. After the initial EA, the major effort of EA is shift to Segment Architecture which is a sub-set of EA to address the dynamic change of business. For EA to be practical, the notional enterprise architecture is only elaborated in the area of business rather than design the entire enterprise in a big-bang approach base on the architects ideology. Segment Architecture is incremental and continuous. On contrary to the holistic and notional target enterprise architecture , segment architecture is executable which support gap analysis, transition plan and modernization.
Table 2 : The CEA approach
Initial EA do not requires significant investment of time and resources
^ TOP
Target Architecture must be holistic
Enterprise Architecture must be decribed evenly accross the EA artifact framework which serve as a check list. many EA effort have not decribe EA evenly by put too much in some area and too little in certain area. The application developement oriented EA effort frequently overlook the enterprise aspec of organization, location and performance requirement.2.1 Describe the Target Architecture based on the artifact framework
The Enterprise Target Architecture plan must be holistic to cover every aspect of Enterprise Architecture at the high level. EA artifact framework, which serve as a check list for comprehensive EA is suggest to describe the target architecture to assure the target architecture has covered every area of EA in a high level and homogeneous manner.
The enterprise target architecture must describe the relation and connectivity between architecture components in different areas of the framework. The relation and connectivity serve as the context to relate and integrate segment architecture
LEA has prototype an interactive EA framework to demonstrate the high level enterprsie architecture.
The enterprise infrastructure framework combine most recognized John Zachman EA framework and the popular EA model to explicitly illustrate the EA framework in the row of business, application, data and technology. It is an effort to distinguish EA from application development. The traditional row of planner, owner, designer, builder and contractor in the John Zachman framework is application system development oriented which do not help to distinguish EA from application development.
The first column in the framework is the reference model for business architecture, application architecture, data architecture and technology architecture. It is include the reference models of BRM, SRM, DRM and TRM which contain the enterprise standards for reuse and interoperability. The other columns describe the enterprise infrastructure from the aspect of why, how, what, who, where, when. The framework define the Product Definition and the Enterprise Definition similar to what John has defined in the Zachman framework. The first three columns on the Enterprise Infrastructure framework represent the product definition. The next three columns Who , Where, When is the Enterprise Definition which describe the people, the location and the workload.
The attributes of Who ? What? When? Where? How? Why has been the question traditionally asked by the journalist. It is an valuable aids to invention in all type of writing. John has adopt the traditional wisdom in the Zachman framework with the sequence of what, how, where, who, when, why. The sequence of these attributes varies depends on different purpose. The enterprise infrastructure framework suggest the sequence of Why, How, What, Who, Where and When due the need that enterprise architecture must know the motivation and mission first. Where is an pertinent attributes to describe the enterprise base on geographical location. The following paragraph describe the framework in more detail.
6.1 Business architecture
Business architecture is considered as the business requirements for the Enterprise Infrastructure to align with business need. The framework shows that the business architecture describe the enterprise from the aspect of Mission (Why) , Function (How) , Information (What) , People (Who) , Location (Where) and Workload (When).
Enterprise Infrastructure is business driven. The application services , the information services, the technology services are designed based on business need to support their common business process automation.
• The business reference model describe the enterprise business area and line of business.
• The Why column describe the enterprise mission. Mission
• The How column describe the enterprise business Functions
• The What column describe the enterprise information subject area
• The Who column describe the demographic
• The Where column describe the enterprise locations
• The When column describe enterprise workload.
6.2 The Application service
The application layer consist of the application services better known as the Service Oriented Architecture (SOA) . The rest of the columns describe the application services architecture which are the consolidation design of application services follow the enterprise application service standards in SRM and based on the enterprise workload distribution. The framework organize the application services from the following aspect :
• The service reference model (SRM) document the application services standards for interoperability.
• The Why column is the business/application alignment to illustrate how business need for application systems.
• The How column contain the business operation specific application services, the business operation services are business specific to different line of business rather generic to the enterprise.
• The What column contain the property related application services such as property management, procurement services.
• The Who column contains the people related application services such as human resources and many related services.
• The Where column contain the location related application services such as
• The When column contains the budget and financial related application services. The time of enterprise operation is determined based on available fund.
6.3 The information resources
As described in the concept of Enterprise Infrastructure, information resources is an integral part of enterprise infrastructure to enable the agility of business automation. The information resources service provides quality data content to support the stakeholders need in analogy to a water company in collecting, treatment , and deliver quality water to the residents in the city. The information resource service consist of data stewardship, data warehousing, data mining and knowledge management. It is an effort to organize, , treated and related to provide quality information for stake holders. The information resources are designed to bring the information close to where it is need. It is analogy to the find the utility companies to serve local area. Information resources does not only contain data but also image , geospatial and multimedia information which demand significant network bandwidth. It must be designed to bring information to the users to meet the users performance requirement.
In the row of information services , the data reference model on the first column contains the data standard such as data model, data structure, naming convention and code standards. Traditionally, most of EA effort have focused on the meta data which is the data structure. The meta data is the mean to organize data and information, the end of information resources service is to serve the quality information to stakeholders.
The data stewardship and data warehouse in the other columns are designed based enterprise business need follow the data standards such as data structure and naming convention and data code in the data reference model . Data stewardship collect and maintain the information in one place to serve the need of multiple application systems instead of redundant effort by every automation systems as it is in stove pipe system. Data warehousing extract, transfer and load which is known as ETL information via data hygiene, data cleansing to support data mining, knowledge management, business intelligence and decision support.
The framework organize the information resources in the following aspect
• The data reference model (DRM) to document the data structure standards.
• The Why column align information resources to business need.
• The How column organize operation related data stewardship (How)
• The What column organize property related data stewardship .
• The Who column organize people related data stewardship. (Who)
• The Where column organize location related data stewardship. (Where)
• The When column organize financing and budget data stewardship. (When)
6.4 The technology infrastructure
The technology infrastructure describe the common technology services to support the enterprise wide application systems. The technology services are designed based on the enterprise workload from the enterprise definition and the technology standards from the technology reference model.
• The technical reference model document the enterprise technology standards and runtime patterns.
• The why column document application technology services such as the application platforms and runtim
• The How column document the integration technology services such as messaging and web services.
• The What column document the information technology services such as the enterprise database engine, the enterprise document management engine and others.
• The Who column document the security technology services such as the single sign on and identity management.
• The Where column document the enterprise collaboration and network technology services
• The When column document the enterprise computing platform services .
^ TOP