Introduction to Management Architecture
The Management Architecture Framework describe the
^ TOP
Communication Management
1.0 INTRODUCTIONThe EA group must communicate throughout all process steps and phases, using any and all forms of outreach media possible (including e-mail, brown-bag lunches, formal presentation, and, of course, a comprehensive and customer –friendly web site). Communication must be both internal and external at appropriate intervals. [13]. LEA further suggest to communicate with stakeholder in the following approach :
• Architecture drawings to see the big picture.
• Web technologies to deliver updated and drill down information.
• Keep stakeholders informed on current environment.
• Architecture liaisons to embed with stakeholders
Most of EA communication has emphasized on the communication between EA community with documents, models, framework, reference models and business models. However, EA has not become popular knowledge in the enterprise due to lack of EA awareness. It is very difficult to comply and take advantage of EA without knowing what it is.
3.0 WHAT IS EA COMMUNICATION
3.1 Communication on architecture artifacts
3.2 Communication to find resources for reuse
3.3 Communication to find resources for sharing
4.0 PURPOSE
Communicating the EA information to stakeholders is essential to achieve architecture buy-in. It is very difficult to comply with the architecture design without knowing the enterprise architecture. The EA group must communicate throughout all processes, steps, and phases, using any and all forms of outreach media possible (including e-mail, brown-bag lunches, formal presentation, and, of course, a comprehensive and customer –friendly web site). Communication must be both internal and external at appropriate intervals. [13]
John Zachman suggests [20] that EA artifacts must be graphically presented. He writes that :
“I would further suggest that ultimately, the Enterprise will require that these artifacts must necessarily be graphically presented because at the point in time when you will need the artifacts, you won’t have the time to read through a thousand pages of text to attempt to discern their implications “
4.1 Keep stakeholders informed on exiting environment
Peer pressure can help on architecture buy-in. Fully informing the stakeholders on the exiting environment is the other way to overcome architecture governance. Governance can be achieved not only by enforcement but also by peer pressure through the sense of community values and culture. Without knowing the enterprise environment, the business owner does not have much choice but to develop stove-pipe system. Fully inform the stakeholders on the existing environment will enable the sense of community and peer pressure on the stakeholders to comply with community standards similar to homeowner in a subdivision.
Learning from the past, pattern analysis from the existing environment establishes building blocks to best suit the agency’s particular organization, culture, and internal management practices. Generic pattern to start from a clean sheet such as the effort of Enterprise Resources Planning (ERP) have encountered different bottleneck because of one size does not fit all.
Documenting existing environment is not trivial as perceived by many people because it is an “exiting” environment therefore it can be taken for granted.. It is easy to see a tree but it need special effort to see the forest. The effort of documenting the exiting environment includes the application system portfolio management and the asset management on the common computing environment. Documenting the existing environment required systematic approach to similar to the geographical survey for urban planning. PEA suggest documenting existing environment from the big picture as implied by the Existing icon implied on the PEA approach framework (figure 1) rather than individual efforts. For example, there are many version enterprise application system lists to confuse the stakeholders.
4.2 Building consensus
Enterprise architects are the facilitators to orchestrate a sharing and reusable environment from the business owners. As much as the CIOs would like to have the budget power to govern the Enterprise Architecture, it is a big questionable assumption by the definition of ownership. Buy-in from the stakeholders empowers the legitimacy of enforcing the architecture compliance as show on the PEA approach framework (figure 1 ). Scott W. Ambler, one of the authors in the Practical Guide to Enterprise Architecture[13], says that Enterprise architecture is all about people, so it is futile to put together an EA governance program based on a “command and control” approach without the participation of stakeholders [2]. Governance process places the political process for making and enforcing IT-related business policies into the business realm of the enterprise.[4]
To overcome the challenge of architecture buy-in, PEA suggest establishing change request process and change control boards to incorporate the needs from the stakeholders. The enterprise architectures compose the initial EA standards, guidelines and architecture design. The stakeholders review and suggest modifying the EA standards, guidelines and architecture design through the change request. The change control boards which are composed of the representatives from both the management and stakeholders incorporate the change requests through political process of consensus. It is similar to the legislative process in a government., the legislative process empowers the legitimacy of enforcement of the standards and regulations.
5.0 THE COMMUNICATION MODEL
The traditional EA communicate with stakeholders in volumes of enterprise architecture documents which become shelfware to fulfill the requirement by the law. []. PEA suggest to communicate with stakeholders in the following approach :
• Traditional architecture drawing sets to communicate the big picture.
• Use the HTML drill down capability and EA database repository to communication the detail architecture information.
• Architecture documentation to describe the processes
• Architecture liaisons to embed with stakeholders .
LEA suggest to apply architecture concept to desing cummunication structure and measure the communication performance.
6.0 THE STAKEHOLDER
7.0 COMMUNICATION SUBECTS
8.0 THE COMMUNICATION TOKEN
The author of this paper have created the architecture drawing sets for business architecture, application architecture, data architecture and technology architecture. Architecture drawings are the architecture protocol to the stakeholders. A hand-drawn sketch today can often be far more valuable then a fully documented and validated document several months from now [2]. Architecture drawings automatically produced by Computer Aid Design (CAD) system serves well to document the architecture design. However, hand-drawn sketch can capture the creative design concept directly from the architects without the mechanical barrier.
9.0 THE COMMUNICATION CHANNEL
To deliver the update architecture products to the right people on the right time, the author of this paper have also developed the e-PEA approach which deliver comprehensive architectural products using web technology. It is not only a dissemination tool but also an EA automation tool which support the governance process of change management process and compliance review.
7.0 COMMUNICATION WITH STAKEHOLDERS
7.1 Who are the stakeholders
The traditional EA communicate with stakeholders in volumes of enterprise architecture documents which become shelfware to fulfill the requirement by the law. []. PEA suggest to communicate with stakeholders in the following approach :
· Traditional architecture drawing sets to communicate the big picture.
· Use the HTML drill down capability and EA database repository to communication the detail architecture information.
· Architecture documentation to describe the processes
· Architecture liaisons to embed with stakeholders .
7.2 Communicate with stakeholders to overcome architecture buy-in
In addition to EA oriented, consensus based and integrated governance processes, communicating the EA information to stakeholders is essential to achieve architecture buy-in. It is very difficult to comply with the architecture design without knowing what is the enterprise architecture. Stakeholder fail to comply with EA due to lack of EA knowledge rather than resistance to EA concept. Traditional EA architecture communicates with stakeholders with volumes of documentation to describe the central planned architecture blueprint. Volumes of enterprise architecture document do not serve well in communication architecture artifact to the stakeholder, it frequently become shelfware [] which stays on the shelf. John Zachman suggests [20] that EA artifacts must be graphically presented . He stated that :
“I would further suggest that ultimately, the Enterprise will require that these artifacts must necessarily be graphically presented because at the point in time when you will need the artifacts, you won’t have the time to read through a thousand pages of text to attempt to discern their implications “
The EA group must communicate throughout all process steps and phases, using any and all forms of outreach media possible (including e-mail, brown-bag lunches, formal presentation, and, of course, a comprehensive and customer –friendly web site). Communication must be both internal and external at appropriate intervals. [13]. PEA further suggest to communicate with stakeholder in the following approach :
· Architecture drawings to see the big picture.
· Web technologies to deliver updated and drill down information.
· Keep stakeholders informed on current environment.
· Architecture liaisons to embed with stakeholders
7.3 Architecture drawings
PEA suggest to use architecture drawings to illustrate the high level big picture rather than a blueprint for design and build as it is in the traditional engineering approach. EA in architecture drawing approach is not new, some EA approach take architecture drawings as a blueprint for design and build and created many drawings only good for use as wall paper. Architecture drawings is very effective on presenting the high level holistic big picture but do not serve well in describing business logic in detail. PEA architecture drawings are particularly useful to communication architecture concept with non-technical stakeholders. The high level architecture drawings , similar to the plan view in a house blueprint, illustrate enterprise architecture concept in explicit pictures to connect the non-technical stakeholder to the enterprise big picture as shown in the following example crated by the author. A hand-drawn sketch today can often be far more valuable then a fully documented and validated document several months from now [2]. Machine produced architecture drawing is valuable to document the architecture artifact after it is designed. The machine produce drawings are complicate and difficult to comprehend with special technology background. The architecture drawings can be presented on both electronically and on traditional paper print hard copy. The electronic versions are easy to distribute to the stakeholders. However, the hard copies of architecture drawings serve better during the communication to the non-technical stakeholders during the discussion. PEA suggest high level architecture drawing sets to illustrate the business architecture, the application architecture, the technology architecture similar to the traditional architecture drawings. The author have created proto type enterprise architecture drawing sets and have been very useful to communicate enterprise architecture with stakeholder
7.4 Architecture liaisons
7.5 Web technology to deliver updated information
PEA suggest to use web technology as a web application with database repository rather than as a web publishing tool. Many organizations use web technology as web publishing tool to deliver architecture documents rather than as a facilitating tool to establish enterprise architecture with the participation from the stakeholders. As a web publishing tool, web technology is not a part of enterprise architecture development until it is completely designed with finish touched after years of effort. PEA suggest to use web technology as part of the enterprise architecture development process from the beginning to deliver EA information as soon as it is available to the stakeholders such as the current environment, standard profile and who are the stakeholders.
PEA suggest use simple and open repository application rather than a complicate and expensive systems. Most of commercial EA repository today offer a variety of complicate modeling tools for business process reengineering, data modeling and application system design to support enterprise architecture as the central planned enterprise architecture blueprint . Traditional EA has been complicate from the beginning to select the proper EA tools. PEA approach keep it simple to look at the commonality rather than analyze the differences, the major requirements of a PEA repository is straight forward to store EA information in a open database. The key to manage EA information is the data standard rather acquiring a complicate EA repository and modeling application. Establishing EA data standard in beginning of EA enable future integration to the other EA tools and IT management tools. PEA suggest to establish the data standard based on the enterprise architecture frameworks. Organize the EA standards in enterprise architecture frame work serve as the chain to link all IT management application such as document library, configuration management, project management, meta data repository , requirement management and asset management together instead of looking for a all inclusive EA repository,
^ TOP