FEAPMO Reference Models
The Federal Enterprise Architecture (FEA) Consolidate Reference Models (CRM) is the effort to enable the IT community to communicate and locate common reusable resources rather than a EA guide or a framework for Enterprise Architecture design. Without making transition from application development culture to EA culture, most of the IT community are looking into the different reference model for Enterprise Architecture guidance. To their dismay, they have conclude that OMB is on the wrong direction.The FEAPMO consist of Business Reference Model (BRM), Performance Reference Model (PRM,) Service Reference Model (SRM) , Data Reference Model (DRM) and Technical Reference Model (TRM) as shown in the follow figure
Figure 2 FEA CRM reference model
The first version of FEA CRM was released on May 2005, and the FEA CRM version 2 has been just released in June, 2006. The BRM introduce the business areas and line of business (LOB). The SRM describe the category of service components. The DRM describe the business subject area , data patterns and standardization. The TRM describe the technology domain, and technology patterns.
^ TOP
Exchange knowledge via reference models
1.0 INTRODUCTIONReference models are introduced to support the engineering of reuse. Technical Reference Models (TRM) has been the lesson 101 in EA , yet it has been the most confusing term in EA among the IT community even in between EA professionals.
EA is the effort to align IT solution with business need. The effort of pattern adoption to learn the IT/business alignment experience from others has raised the question of “where to find the patterns for adoption ?” ERM is proposed to enable the stakeholders to find the patterns based on their line of business and performance requirements.
1.1 The values of reference model
Reference models are essential in the engineering of reuse. It is not only serve as the reporting reference to OMB as some EA professional suggest. It may appears have little values in the stovepipe culture because they do not have to learn from the other. But it is critical in EA to enable the concept of leaning the experience of the others. The major challenge for the engineering of reuse is how to learn the experience from others. The concept of reuse to learn the experience of the others, eliminate redundant effort and enable ability is not hard to sell, the real challenge is how to exchange the knowledge of reusable resources to find the proper components for reuse.
1.2 It is new to the stovepipe culture
Reference models are new to the stovepipe culture. It requires a culture transition effort to understand the concept of reference model. In the self sufficient stove pipe application development culture, reuse is not a concern and there is no need to comply with any common standards. EA is initiated to resolve the challenge of stove pipe system.
However, outside the circle of EA professional, the term of reference model is rather intimidating. it is not unusual to see the blank expression from the stakeholders by mention the reference models. Instead of facilitating the EA communication, it has become a barrier that the EA professionals have to explain what is a reference model first. The concept of reference models is new to the application developers and unfortunately they are the most important customers of EA.
Reference models are particular useful to facilitate communication between the subject experts particular in the network communication area that it has been considered as the engineering language. But , the concept of reference model have not serve well in the application developers community because during the age of stove pipe system development, there is not much communication betweens each application development project. EA is initiated to align IT with business and resolve the challenge of stove pipe system, it is essential for application developers in different project to communicate with each other for the purpose of share and reuse. It is critical for the application developers to understand what are the reference models for
2.0 WHAT IS REFERENCE MODEL
Reference models are used to facilitate the exchange of reusable knowledge by using the same terminology and in the same context to assure the accuracy of communication to exchange the reusable knowledge. It establish a common language for the knowledge of reusable resources to learn from the experience of the others. Reference Models are introduced by EA as the reference to find the reusable resources. Reference models are used in the engineering of use for communicate standards in an organized approach
Reference model was introduced by the evolution of EA as the reference to find reusable resource
2.1 Reference model for the engineering of reuse
2.2 EA professional facilitate reuse via reference models
EA professional are trained to master the knowledge of reference model .
3.0 THE BACKGROUND
3.1 Initiate from technical reference model
OSI reference model has been considered as the most successful reference model. it is essential to facilitate the network engineering conversation.
3.2 Evolved to every architecture layer
The Federal Enterprise Architecture (FEA) Consolidate Reference Models (CRM) is the effort to enable the IT community to communicate and locate common reusable resources rather than a EA guide or a framework for Enterprise Architecture design. Without making transition from application development culture to EA culture, most of the IT community are looking into the different reference model for Enterprise Architecture guidance. To their dismay, they have conclude that OMB is on the wrong direction.
The FEAPMO consist of Business Reference Model (BRM), Performance Reference Model (PRM,) Service Reference Model (SRM) , Data Reference Model (DRM) and Technical Reference Model (TRM) as shown in the follow figure
Figure 2 FEA CRM reference model
The first version of FEA CRM was released on May 2005, and the FEA CRM version 2 has been just released in June, 2006. The BRM introduce the business areas and line of business (LOB). The SRM describe the category of service components. The DRM describe the business subject area , data patterns and standardization. The TRM describe the technology domain, and technology patterns.
4.0 THE MYTH OF REFERENCE MODEL
This article intend to clarify the concept of reference model by identify the myths of reference and distinguish the difference between reference model and EA framework.
Reference models are introduced in EA as the reference points for the EA community to exchange reuse knowledge and learn experience of the others. In the EA community, we all talks about reference models, It has been the lesson 101 of EA. however, with a different degree of confusion. It is due to the fact the concept of reference models are new to the stovepipe culture where they do not have to learn experience from the others. The confusing occurs not in the IT communities but also in the EA professionals, it is a torture to watch an EA instructor to teach an EA course with complete confusion between Reference Model and Architecture framework.
4.1 Myth #1 Confusing Reference Model and architecture framework
The major myth of reference model is using reference model to describe their architecture. Many EA professional try to use reference models to describe the architecture. Reference Models are not part of the architecture, it serve as the reference to find standards and communicate the reusable resource.
4.2 Myth #2 Confuse reference model with reference manual
Many organizations have made significant investment on Technical Reference Manual and claim that is their enterprise architecture. A technical reference manual describes the technology, the principle, the technology components and the best practice similar to an engineering handbook. The content of a technical reference manual is essential the same, it is a redundant effort for each organization to development a reference manual. Contractors love it, they can skin many time from the same technical reference manual. Some organization invested on the technical reference manual and claim that as their enterprise architecture. The truth is that an technical reference manual should not be considered as their enterprise architecture, similar to that an engineering handbook is an architecture design.
5.0 DISTINGUISH REFERENCE MODEL FROM FRAMEWORK
The following table conduct the analysis to distinguish a reference model from a architecture framework from the aspect of purpose, scope, consistency and simplicity.
5.1 What is a EA Framework
EA frameworks are initiated to describe and guide the EA architecture approach, it covers the entirety as the union set of enterprise architecture. Enterprise can use different EA frameworks based on their needs and available resources. EA framework can be very complicate to have different views as demonstrated in the Zachman framework, the TOGOF framework, the FEAF framework and the DODAF.
5.2 What is a reference model
Reference models are initiate to facilitate the exchange of reusable knowledge and learn the experience of the others. It is very different from the purpose of architecture framework. It identify the commonality for reuse as the intersection set of enterprise architecture. It is import to have a unified reference model with consistency in the EA community to achieve the goal of communication as a language. The reference model must base on a simple view to enable clear communication to avoid the comparison between apple and orange. It is not intend to illustrate the connectivity between the architecture component.
6.0 FEAPMO CONTRIBUTE TO THE CONFUSION
FEAPMO contribute to the confusion of Reference Models by making the abrupt change of course from the Federal Enterprise Architecture Framework (FEAF). At 1990s, the Federal Enterprise Architecture Working Group has developed the Federal Enterprise Architecture Framework (FEAF) and the Practical guides for architecture design approach. It takes a while for the EA community to settle down on the FEAF concept. However, without making a smooth transition in the EA community, the Federal Enterprise Architecture Program Office (FEAPMO) has made a sharp turn to switch their focus on FEAPMO referenced models. It is a very different direction which is enough to stir up the confusion of the EA community which just settle down on the EA framework
Although it is the logical step for FEAPMO to evolve the focus from architecture framework to reference models, their abrupt switch of focus from architecture design framework to reference model, without a smooth transition has contributed the deep confusion of reference model which is significant to cost the value of reference models. Some EA experts have declared that the Reference Models has little value but only serve the purpose to create reports to make OMB happy. Once again, the good intention of OMB has been received as the burden rather than the benefit.
7.0 THE FUNDAMENTAL ISSUE IS THE EA MODEL
EA model must explicitly incorporate the concept of reuse rather than implicitly embed the concept which defeat the purpose of modeling. The explicit modeling of reuse will enable the culture transition from stovepipe culture to the EA culture as shown in the following figure :
7.1 The traditional EA model embed the concept of reuse
The traditional EA model, evolved from water fall approach, without explicit modeling the reuse, has minor difference between EA and stovepipe application development. As a result, EA is better known as an enterprise scale application development.
7.2 The LEA model explicitly incorporate the engineering of reuse
The LEA model suggest the twin model to explicitly model the engineering of reuse to clarify the myth of reference model. From the LEA model, the EA community can clearly distinguish that the reference models are for the purpose reuse and Architecture frameworks are used guide the architecture design to consolidate resources ^ TOP
The mytth of EA
The is part of the Light Enterprise Architecture effort to identify the myth of EA. so far, we talk about EA is more the high level talk , EA is not static , EA is not only for large organization, EA is not only about architecture design, EA is more city planning than building architecture Distinguish EA from business transformation.Enterprise Architecture is very different from Enterprise solution. Enterprise Architecture is the effort to align technology to enterprise business. It is a place of everything and every thing in its place. EA is more about the relation between many different objects. Enterprise solution is about scalability.
Many IT oriented professional have confused Enterprise Architecture to Enterprise Solution. To them, the enterprise architecture is about scalability where the solution is able to support the Enterprise with proper resources. When it comes to describe their enterprise architecture, they will provide a list of enterprise scalable solution such as SOA, J2EE standard, .Net without touch the Enterprise definition. Some will tell you that Enterprise definition is irrelevant because of that there solution can be scale to any enterprise.
Sounds very right but some one still has to map the solution to enterprise business. The key is to see the forest and know the enterprise business. In EA, application architecture is defined as how the application system map to business function and process rather describe what is the application is composed of. In the other word, it is about what kind vehicle to use to achieve the business purpose rather than how is the car made of.
^ TOP
Agility via Engineering of Reuse and Sharing
Light Enterprise Architecture enables the agility, simplicity and cost effective via the engineering of reuse and sharing by leering experience of the others and sharing common foundation and building blocks. 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 are based on the number of people and how hungry they are. The criteria to reuse a pie are learning 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.
By learning experience of the others, we can overcome the challenge of waterfall solution and enable agile solution because there is nothing new under the sun, particular in the area of common foundation and building blocks. The engineering of reuse and sharing learn from the same line of business identified in the business architecture without conducting redundant waterfall analysis to establish the common foundation and building blocks.
^ TOP
Agile top down
The agile top down approach enable an enterprise to establish their common foundation rapidly in time for practical need without waiting for the traditional waterfall analysis. It is accomplished by align IT to business based on the lines of business in the enterprise.Agile top down approach is based on the concept of pattern adoption instead of pattern recognition. It suggests to establish the common foundation via pattern adoption from the established patterns the same lines of business.
John Zachman's has suggested that
" Based on the Framework for Enterprise Architecture, I would suggest that Enterprise Architecture is the set of primitive, descriptive artifacts that constitute the knowledge infrastructure of the Enterprise. ?Reuse or interoperabitliy does not happen by accident. It is the result of engineering " [15]
Enterprise Architecture have devoted to the engineering of reuse since its inception. Standardization using technical reference model has been the first step in the engineering of reuse, traditional EA approach such as the popular Enterprise Architecture Planning (EAP) approach establish the common foundation based on the waterfall concept to conduct pattern recognition. IBM have introduced the patterns for e-business to establish common business solution as describe in the following paragraphs.
Technical reference models (TRM) have been the most popular reference model to convey technology standard profiles to the stakeholders. The stakeholders of enterprise architecture need to know what is the standard profiles and where are the share resources before they can complying to the standards and access to the share resources. As the industry tend of services oriented architecture, the reference models have also evolved to incorporate the service reference model, the data reference models.
Read More → ^ TOP