Previous column

Next column

---

A Picture is Worth a 1000 Words? Mahesh H. Dodani, IBM Software, U.S.A.

COLUMN PDF Version

1 SOA PICTURES

“Today, if N architects are asked to draw an SOA, they will produce N different pictures, all labeled 'SOA'.”
Sean McGrath, http://www.itworld.com/nl/ebiz_ent/03012005/

In a previous article (http://www.jot.fm/issues/issue_2005_07/column6) I presented the effort on addressing depth in the practice of SOA through the details of reference architectures, roadmaps, and governance. I focused on SOA reference architectures which define the key enabling technologies (services, web services, open standards, etc.), the realization of key SOA principles (composability, loose coupling, reusability, etc.), the details of key architectural layers and components (service provider/consumer architectures, enterprise service bus, component architecture, etc.), and the realization of these components through hardware, software and services.

Within IBM we are focusing on two main perspectives to articulate SOA pictures:

• A layered service perspective that shows the composite services that align with business processes, as shown in Figure 1 below. The layers show how enterprise-scale components (large-grained enterprise or business line components) realize the needed services and are responsible for providing their functionality and maintaining their quality of service using the operational systems. These exposed services are choreographed into composite applications to support business processes. Consumers access these exposed business services through a variety of interaction channels. The vertical layers describe capabilites that are needed to support the services across all other horizontal layers. The integration capabilities supports the interaction between services. As a specific example of the integration capabilities, an Enterprise Service Bus (ESB) supports the routing, mediation, and translation of these services, components, and business processes. The services must be monitored and managed for quality of service and adherence to non-functional requirements. The data architecture supports the storing and manipulation of service meta-data and information. Finally, the service location, version, service-level agreements, and subscription level are handled by approprite governance models.

Figure 1: SOA Picture – Layered Services Perspective

• A capabilities perspective that shows the key functionalities that are required to implement comprehensive, enterprise wide SOA solutions, as shown in Figure 2. The Development Services are used to implement custom artifacts that leverage the infrastructure capabilities, and Business Innovation & Optimization Services are used to monitor and manage the runtime implementations at both the IT and business process levels. At the core of the SOA Reference Architecture is the Enterprise Service Bus which delivers all of the inter-connectivity capabilities required to leverage the services implemented across the entire architecture. Transport services, event services, and mediation services are all provided through the ESB. The SOA also contains a set of services that are oriented toward the integration of people, processes, and information through Interaction Services which provide the capabilities required to deliver IT functions and data to end users, meeting the end-user's specific usage preferences. Process Services provide the control services required to manage the flow and interactions of multiple services in ways that implement business processes. Information Services provide the capabilities required to federate, replicate, and transform data sources that may be implemented in a variety of ways. Many of the services in an SOA are provided through existing applications via the Access Services; others are provided in newly implemented components via Business Application Services; and others are provided through external connections to third party systems via the Partner Services. Underlying all these capabilities of the SOA is a set of Infrastructure Services which are used to optimize throughput, availability and performance. IT Services Management Services include capabilities that relate to scale and performance, for example edge services, clustering services, and virtualization capabilities allow efficient use of computing resources based on load patterns.

Figure 2: SOA Picture – Capabilities Perspective

The astute reader would realize that I used a around 1000 words to explain each of these pictures! Are these SOA pictures sufficient to explain how to architect, design and build appropriate solutions? Obviously not! In order to use these pictures, we need detailed descriptions, reference solutions, usage guidelines, mappings to technologies and products, implementation guidance, etc. So, what is missing from making these pictures meaningful and useful?

2 SOA MODELS – MAKING PICTURES MEANINGFUL

An emerging approach to making pictures meaningful is creating machine-readable models. A model is a description of a system from a particular perspective, omitting irrelevant detail so that the characteristics of interest are seen more clearly. Models help us to more easily understand complex technical environments such as a business domain or the architecture of a proposed solution. They enhance communication among stakeholders with different technical backgrounds and among disparate teams within an organization or across multiple organizations. Model-driven development is a style of software development where the primary software artifacts are models from which code and other artifacts are generated. Models are either derived from other models through well defined description languages or are formally transformed between layers of abstractions (e.g. from analysis models to design models to code.) This transformational approach to models is formally defined through a model-driven architecture (http://www.omg.org/mda/) by the OMG (Object Management Group), and is shown in Figure 3.

Figure 3: Model-Driven Development

As shown in the figure, the CIM does not show any system details and is often called the domain model because it is defined by business requirements. The CIM plays an important role in bridging the gap between requirements experts and design experts. The requirements experts focus on the business domain, whereas the design experts must connect new technology with artifacts to meet domain requirements that result in a PIM. Once the PIM is defined, the PSM (including the analysis and implementation models) can be generated using a transformation process based on the chosen implementation platform.

Applying this model-driven approach to SOA leads us to the concept of business-driven development, which describes a a methodology for developing IT solutions that directly satisfy business requirements and needs, as shown in Figure 4.

Figure 4: Business Driven Development

As shown in the Figure, a good architecture begins with a solid understanding of the business requirements; which in turn require a solid understanding of how the business works today, and how it should work in the future. Models (and the associated tools) document the business requirements (and goals and objectives) and create an “as-is” model of the business process. From these models, we can identify deficiencies and pitfalls and create a “to-be” model for how the business can be improved. These models can then be used to simulate the to-be process to validate cost savings, ROI, and other general improvement parameters. Once optimized and validated, the architect exports the to-be model via UML for further manipulation. The architect uses appropriate tools to transform the business requirements into software system requirements and models. This approach will ensure that the system implementation is driven by business requirements and is fully aligned with the business process model.

The architect imports business processes and refines application design, based on best practices and existing assets. An operational model will help the operations team plan the future deployment. The developer implements the application by leveraging best practices including highly productive J2EE capabilities. Built-in code analysis & unit testing capabilities enable developers to fix functional, performance, and security problems at the component level – early in the development cycle. Identifying and fixing problems at the component level greatly reduces the overall cost of delivering high quality applications. The application is validated to ensure that it functions as designed with acceptable performance. The functional and manual testing tools accelerate quality assurance activities as they build a valuable foundation of reusable test artifacts. The application models are assembled and deployed onto the runtime environment. The Operations Manager monitors application performance and is automatically notified of problems, enabling fast triage to the right stakeholders (application, DB, network, etc.). Appropriate tools provide a centralized view into the network, systems, middleware, and application performance.

3 CONCLUSION

In conclusion, we need more than just pictures to facilitate consistent, effective and efficient use of architectures, designs, and best practices. Model-driven approaches allow us to give these technical pictures meaning and formally transition and transform between them. It facilitates communication between the various people involved with realizing a system – from business analysts, through architects and designers, to developers and testers, to implementers and operations managers, and to both business and technical monitors.

About the author

Cite this column as follows: Mahesh Dodani: “A Picture is Worth a 1000 Words? ”, in Journal of Object Technology, vol. 5, no. 2, March-April 2006, pp. 35-40 http://www.jot.fm/issues/issue_2006_03/column4