by Gabriel Bechara
Archived Article - Originally published on BEA Arch2Arch March 2006
As mentioned, services offered by the functional building blocks are ideal candidates for SOA building blocks. Service identification done this way, using a top-down approach, will lead to a better mapping between the business requirements and IT.
Services implementation on the applications plan will depend on the type of services and the relation to the different SOA layers—those layers being the presentation and composition layer, the orchestration layer, the business services layer, and the data access layer or connectivity layer.
The correct product for implementing those blocks should be considered carefully. This choice will depend on the organization's context in term of existing applications and technical constraints, the applications plan choices correlating with the technical plan when it comes to implementation choices. In an ideal world, BEA WebLogic Integration is the choice for system-to-system processes. BEA AquaLogic BPM, used on the business process plan for design and process reengineering, is the ideal choice for human-driven processes. BEA WebLogic Portal is the ideal choice for developing and sharing presentation layers throughout the entire organization through WSRP promoting reuse of the presentation layer and portal federation. AquaLogic Data Services is the ideal tool for the data access layer, and AquaLogic Service Bus is the ideal choice for application-to-application communication. In the real world, the choices will depend on the organization's existing assets and needs; a reference architecture should be considered in the context of the organization.
The organization's reference architecture should be defined providing the best practices and blueprint on how to implement each of the building blocks, depending of the layer the service belongs to. Communication between services is also defined and demonstrated in the reference architecture. Figure 2 shows an example of defining a reference architecture for one organization; this diagram also describes the SOA layers that may be needed for implementing the services of the functional building blocks of the organization using the appropriate products. The reference architecture definition is achieved through a process that involves the appropriate business and IT players. It provides a model for implementing the building blocks for each SOA layer using the relevant products in the context of an organization and in alignment with the business strategy.
The reference architecture should also promote best practices, guidelines, and design principles defined by the governance team. This architecture should use the canonical models and the taxonomies defined in the functional plan. I will discuss the governance team definition later.
In taking a holistic approach, starting from the business needs of an organization, the main objectives of enterprise architecture is building a culture of reuse through a common language, as shown in Figure 3. This should be done in an evolutionary, not a revolutionary, way, with a governance team acting in an operational environment with different scopes: the global business and strategy scope, the information systems scope, and the projects scope. Support should be provided using the right tooling for promoting reuse throughout the organization.
The governance team should create and maintain assets reflecting the current state of the organization in terms of existing functional blocks. In those assets, a global description of the current state is done; this should help identify the silos of the current information system. A target state should also be defined associated to a roadmap.
To be able to apply the roadmap to the target, the governance team should be present in the new project from their inception, providing guidelines and enforcing common rules and best practices throughout the organization.
Principles, policies, taxonomies, enterprise canonical data models, data repositories, best practices, reusable assets, and guideline should be defined and maintained with the governance team involving all lines of business and IT.
The enterprise architecture should align IT with the strategy of the organization. It has the objective of providing an agile information system that can be adjusted easily to the continuous changes of the business. This dictates the business frameworks and principles leading to the functional building blocks that are necessary for the composition, and recomposition of the business processes.
The enterprise architecture team references the existing functional building blocks. It also defines new functional building blocks needed for the business processes as defined in the global business scope in the business processes plan. The information systems scope relates to the functional plan and should provide the correct level of abstraction using a common language understandable by business and IT.
Information systems assets are defined in the functional plan. This definition includes the communication between applications in the functional level along with canonical enterprise data models, common language, taxonomy, and data repositories. The access to those assets should be defined and controlled.
The work on the functional plan should be mapped to applications in the applications plan. Standards and product support should be identified in association with the aspects covered by the each of the applications. The reference architecture is defined within this scope.
On the operational level, most of the actions should be done with projects to insure that the principles and guidelines are applied. Architects from the governance team should insure that the detailed technical requirements and project architectures are in compliance with the enterprise principles, policies, and uses of the enterprise common language. Applying the architecture blueprints to deliverables for projects in the early stages of the investment cycle increases the odds of delivering on time, on budget, to specification, with quality, and with enhanced reuse capabilities. In this way, projects can provide new SOA building blocks that can be reused throughout the entire organization.
Applying the holistically driven approach to new projects provides an evolutionary way toward the target—a smooth path rather than a big bang.