An Introduction to Enterprise Architecture

Enterprise Architecture Repository Management

Access to the definition of the enterprise canonicals models should be available holistically to develop a common enterprise language, using a common taxonomy. Reuse cannot be achieved without a common language. Efficient management of information system assets is provided using an enterprise repository. This repository should be accessible by the whole organization and managed by the governance team, giving an expanded view of assets and metadata. The BEA AquaLogic Enterprise Repository is the right tool for supporting enterprise architecture.

A methodology in brief

A good start for enterprise architecture is to describe the current status on every plan described above, as shown in Figure 4. This will help assess the gap between business and IT and identify the silos. Then a roadmap is defined to try to reach a target. A methodology consists of going through the different plans described in the beginning of this article for assessing the current state and defining the target state.

Figure 4. A methodology in brief

Current state (as is)

The current state assessment can be done with a top-down approach, a bottom-up approach, or a mix. The definition of the current state is done on every plan.

Starting with the business processes, common work should be done with the line of business and IT to define the current state of the business processes. Modeling those processes with AquaLogic BPM Designer will provide a common ground between architects and business representatives; AquaLogic BPM provides enhanced graphical drawing of business processes and simulation possibilities.

Starting from the bottom, meaning the existing applications, and working with IT, existing functional blocks are identified. Thereafter, duplicated functions may appear and silos would be identified.

Once the siloed applications are identified, a way to un-silo them through service exposition should be defined in the target state.

Target state (should be)

Defining the target state should be done using a top-down approach. This is the recommended approach since it is built on the business needs and will provide reusable business building bocks.

Starting from the business processes, working with the lines of business, optimized future state processes are modeled using AquaLogic BMP Designer. Going down, functional blocks are identified providing the services that are needed for business processes composition and recomposition. Remember that on the functional plan, common work should be done by business and IT.

Roadmap

A roadmap is then defined to reach the target of an intermediary, approved state (will be). This roadmap is the result of the common work done between business and IT. This roadmap should take into consideration the definition of a common language, of canonical models, of data repositories, and so on. Intermediary validations steps should involve business and IT.

The reference architecture is planned at some stage of the roadmap. Planning for the reference architecture can be done at any point, however you should not wait until all enterprise assets are defined to start preparing your reference architecture. It is a living asset that should constantly adapt to new business needs (new functional blocks involving new methods of implementation); it has the objective of showing the "how to," depending on the enterprise reusable assets that exist at the moment and the technology that should be used. As stated before, the reference architecture is in constant evolution providing the best way do implement new projects at a certain time, in the context of an organization, with the objective of enhanced reusability.

The governance team is the main team involved in the roadmap since it will be acting holistically in the organization through the new projects, using the assets it has produced, with the focus of providing the agility required by the business. The governance team should consist of a group of enterprise architects with different backgrounds so they can focus more or less on one of the plans. Architects with a technical focus and with a business focus are needed to drive this governance. Composing the governance team can be achieved by mixing lead architects from the different lines of business and leads architects from IT, providing the necessary credentials to this team to be able to lead this holistic approach.

The task of the governance team can be very difficult in some contexts, and a strong sponsor should be provided. The governance team role may more or less be like an alchemist's; it is about trying to find the right formula to make the adequate transformations happen. Remember that it is important to consider change management disciplines when applying the roadmap.

Relation with the BEA SOA 6 Domains Model

The approach described here started from business strategy and processes through functional building blocks resulting in applications, all this being done around a common enterprise language with a reference architecture providing a blueprint for new projects and applications. On the functional plan, I covered the aspects that need to be handled by the organization and governance to maintain a structured view and to expose successfully reusable assets through the enterprise.

In the context of using SOA as a foundation for enterprise architecture, SOA-experienced architects are needed to avoid common, costly pitfalls that can occur. Those architects should work with the organization's governance team to provide the necessary skills and help the governance team make a successful SOA. SOA can be driven holistically in the context of an enterprise approach or locally in projects. A holistic approach, by providing governance and directions for projects, will surely deliver greater consistency for SOA and a better return on investment. It will also reduce the maintenance costs of applications in production, enhancing their reusability.

BEA has a domains model for approaching enterprise architecture. This model covers the previously described plans (and more) through six areas, providing a path for implementing a successful SOA, as shown in Figure 5.

Figure 5. The BEA domains model

The BEA SOA approach is a pragmatic enterprise architecture approach that addresses all aspects of information technology. BEA has service offerings and education covering all six domains and organized in such a way to allow you to implement SOA to meet your organization's needs.

The BEA SOA Readiness Assessment Report is a good place to begin. It can help in defining the current state and can be a good starting point for introducing SOA in your organization. You can take a survey at the SOA Resource Center, and you will receive a personalized SOA assessment report.

Conclusion

This article presented an explanation of top-down enterprise architecture, explaining the governance considerations that are needed to achieve reuse holistically across the organization, emphasizing the necessity of an organization's reference architecture, and defining an enterprise repository as a way to help promote this global approach.

Gabriel Bechara has worked with Oracle-BEA presales and consulting services since 2003. A 15-year veteran of the software industry, Gabriel has served as an architect and advisor on large projects, providing practical experience and feedback on concepts that can provide a foundation for building new information systems. His interests include methodologies for defining software and enterprise architectures, with a strong focus on business integration and SOA.