Build and refine your enterprise architecture with SOA

Harnessing SOA benefits with a systematic, incremental approach

Enterprise architecture is older than SOA. Yet as SOA stabilizes and matures into a mainstream discipline, you can reap benefits by adopting SOA at the enterprise level. In this article, explore how you can leverage SOA to develop and mature your organization's enterprise architecture.

Share:

Tilak Mitra, Certified Senior IT Architect, IBM

Author photoTilak Mitra is a Senior Certified Executive IT Architect in IBM. He specializes in SOAs, helping IBM in its business strategy and direction in SOA. He also works as an SOA subject matter expert, helping clients in their SOA-based business transformation, with a focus on complex and large-scale enterprise architectures. His current focus is on building reusable assets around Composite Business Services (CBS) that has the ability to run on multiple platforms like the SOA stacks for IBM, SAP and so on. Tilak recently coauthored a developerWorks series book: Executing SOA: A Practical Guide for the Service-Oriented Architect, available in the resources section. He lives in sunny South Florida and, while not at work, is engrossed in the games of cricket and table tennis. Tilak did his Bachelors in Physics from Presidency College, Calcutta, India, and has an Integrated Bachelors and Masters in EE from Indian Institute of Science, Bangalore, India.



16 September 2008

Introduction

Service-Oriented Architecture (SOA) has been around a long time. But before adopting SOA corporatewide, organizations justifiably want to be able to see the benefits of it. Many organizations and consulting firms have taken a variety of approaches when trying to demonstrate the value of SOA. Some of these approaches are to:

  • Focus solely on technology—with tools, products, middleware, and infrastructure forming the SOA.
  • Take a process-centric approach by adopting a methodology to analyze, identify, specify, and realize services that adhere to the principles, best practices, and guidelines of SOA.
  • Look at it from a business strategy perspective by aligning IT initiatives and funding based on business goals and imperatives.
  • Take it a notch higher by developing and offering industry solutions that solve specific business problems with a combination of service-oriented technology frameworks, assets, tools, methodologies, domain knowledge, industry standards, products, and infrastructure capabilities all baked into an out-of-the-box solution.

Let's take a step back from this jumble of approaches, and try to analyze what is required for an overall framework that harnesses the corporatewide benefits of SOA. Enterprise architecture can fit that bill.

In this article, learn how you can leverage SOA to systematically develop an organization's enterprise architecture and realize the benefits of SOA. An SOA governance framework is mandatory to help the enterprise adopt SOA at the right level—and in a capacity that is commensurate with the requirements of each architectural facet of enterprise architecture.

Though this article is not about SOA governance, it provides key pointers on the responsibilities of the SOA governance framework to help leverage SOA at the different levels of enterprise architecture.


SOA maturity and enterprise architecture

Assume you're taking a services approach to SOA, and you have the best method, tools, techniques, and frameworks to influence your clients. It's a futile endeavor unless they see tangible and measurable benefits that directly help them mature their own enterprises in terms of business and IT. A major goal of SOA governance is to help an enterprise systematically and incrementally mature in its vision of companywide SOA adoption.

SOA is as much a business imperative as it is an IT imperative. An enterprise that seriously wants to adopt SOA should think about developing its own enterprise architecture. Moving up the SOA maturity ladder is best demonstrated through the development of the corporate enterprise architecture that uses SOA in various disciplines (architecture, organization, methods, and tools). Enterprise architectures, along with organizational adaptability and change, are among he most important maturity indicators for SOA. Good results for the maturity indicators reflect a successful rendition of the SOA governance capabilities.

SOA maturity is firmly rooted in the organizational culture of the enterprise and how it fosters the adoption of SOA. Associated with the organizational culture is a corporate lingo—an unambiguous language to represent business and IT capabilities using a service nomenclature. Using a common modus for business-to-IT communication helps both domains think about software services as first-class enterprise assets. The service assets have a meta-model with embedded attributes surrounding SOA maturity. Examples of these attributes are:

  • Standards adoption or incorporation
  • Regulatory compliance
  • Service modeling and design technique adoption

Meta attributes such as these ought to be defined by the governance council. Attaining higher quality results for the attributes is an incremental but steady step toward the top of the SOA maturity ladder.


Overview of enterprise architecture

Enterprise architecture is described differently by various consortiums, such as TOGAF, and vendors such as IBM®, BEA, and so on. A careful analysis of the well-known definitions lets us derive a very simple view of enterprise architecture. Enterprise architecture comprises four main foundations: business architecture, application architecture, information architecture, and technology architecture. Each architecture is a full-blown discipline in its own right, but enterprise architecture unites the four domains under a single unified enterprise view. Figure 1 shows a simple view of enterprise architecture.

Figure 1. High-level view of enterprise architecture constructs
EA constructs

Business architecture

Companies that prefer a top-down approach to service orientation should ideally start by defining a studied business architecture. While typical enterprises consider their "as-is" business processes to be their entire business architecture, the governance board should ensure that the business stakeholders acknowledge that their business architecture has both a static and a dynamic model. The dynamic model is minimally represented by documented "as-is" business processes and ideally by "to-be" business processes. The static model however, is something that needs more work. The SOA governance council recommends that the entire business landscape be deconstructed into a set of business components.

Business components are discrete and nonoverlapping, with each component encapsulating a set of business functions. The business functions are exposed as a set of business services. In order for the business component to support its business function, it may also need to consume a set of business services that are exposed by some other collaborating business component. Hence, a business component is documented to support a set of business functions that it realizes through a set of exposed and consumed business services. A set of business components may be categorized as a business competency. Think of a business competency as a high-level business domain (for example, primary distributions or retail operations). Each business component is more of a functional area inside a business domain. Such a componentized view of the business lets stakeholders visualize and interpret their business as a network of collaborating business components.

The static business architecture is represented by a set of business components that are categorized by business competencies. The SOA governance council must:

  • Foster an iterative mode for development of such business architectures for the enterprise.
  • Develop criteria to help measure the incremental realization of the architecture goals.

The governance council must analyze the business architecture artifacts and outputs to identify areas where IT investments are important for business transformation initiatives. A well-planned business architecture provides a perfect platform to develop business metrics to measure the effectiveness and value of the business services. The business-to-IT alignment ensures that the enterprise is marching toward increased maturity levels in its SOA.

IBM's component business model (CBM) technique provides guidance on how to develop your corporate business architecture (see Resources).

Information architecture

Many organizations want to offer an aggregated, one-stop shop to their customers. But this can be a challenge with unstructured growth of corporate information and data. Typically, growth of an IT department over decades is not well planned or coordinated for a consolidated, single source of information and data. Customer data is a common example. Consider the sales representatives complaining about not being able to offer life insurance to a client who is trying to buy home or auto insurance. The customer profile information is different, and not synchronized, between the two systems of record. Federated information and data can benefit from SOA by having business-aligned critical information exposed as a set of information services.

SOA introduces a set of information service patterns that can be used to cleanse, aggregate, and consolidate data, which can then be exposed as a service for applications to consume. Exposing critical business information lets you associate a premium value to your information; you can remove the need to weed through various information sources to get relevant information.

Governance is a key underpinning to the SOA life cycle. Patterns enhance the governance process by reinforcing common practices with predictable outcomes. When you're developing systems, reusing proven flexible patterns can ensure consistency and quality and reduce maintenance costs by having just a single source to update with changes.

Application architecture

An application architecture provides the perfect platform to leverage SOA principles when the fundamental building blocks of the technology and information architecture are exposed as a set of services. It allows you to develop and modularize new applications. You can also deconstruct and modularize existing applications, then reconstruct them as a set of services. Their interdependence on the underlying information and technology layers can be represented as a set of collaborating and composable services.

Application architecture can go through various phases of SOA maturity. It usually starts by identifying a set of atomic services, some of which may initially tend to be very IT-focused. (An atomic services is an IT service that encapsulates a repeatable IT function and satisfies the criteria to be exposed as a service.) Atomic services are typically moved into higher order composite services. Compositions of atomic services, in the context of a specific business problem, are then identified as a unit of invocation (because they provide higher order business value than what's provided by exposing just the individual atomic services).

The genesis of the composite business application can be traced back to Gartner's definition of a service-oriented business application (SOBA). A composite business application solves a particular type, or set, of business problems in a particular domain in a particular industry.

A cohesive collection of composite and atomic services packaged together may be offered to clients as a ready-made solution. With enough capabilities, you can configure the collection to suit the client's requirements. Such a packaged solution is a composite business service, or composite business application.

Organizations that are higher up on the SOA maturity ladder are using their SOA governance processes and framework to execute SOA principles, guidelines, and best practices for service-oriented analysis, design, and modeling. Service-Oriented Modeling and Architecture (SOMA) is a proven method for such initiatives. SOMA helps an organization develop business-aligned IT services, both functional and technical in nature, that form the basis of an enterprise's application and integration architecture. Such organizations can advance from identifying and building atomic services to composite services, and then on to building composite applications. This type of maturity road map, which is by no means a trivial achievement, needs to be carefully planned and monitored. The SOA governance processes enable such organic growth.

Technology architecture

Most enterprises typically start their SOA journey from the foothills of the technology architecture. The technology architecture provides the infrastructure capabilities required to support an SOA:

  • SOA products for the run time management and monitoring of services and business processes
  • Technology adapters to heterogeneous packaged applications (such as SAP, Siebel, or other software vendors), file systems, databases, and real-time data systems
  • Registry and repository products for provisioning and versioning the enterprise services
  • Dashboards to provide a personalized view of the SOA metrics for both the business and IT professionals in the enterprise
  • An enterprise service bus (ESB) to perform the message transformation, information mediation, and service-routing requirements to orchestrate services and realize end-to-end business processes
  • Security-related infrastructure products to help externalize security related information from the services and to provide a seamless propagation of security credentials across heterogeneous system boundaries (for example, a Web container, application server container, legacy systems such as CICS®, and so on)

Technology architecture provides the SOA infrastructure framework that is required to develop the enterprise services. Technology architecture modernization may be a reasonable starting point, albeit arguable. The SOA governance council must formulate a plan for acquiring the right tools and products to meet the requirements for the enterprise.

For example, the governance board might mandate the procurement of only those products that help in the service modeling and design. Then, when the company moves into the subsequent phases of the SOA life cycle implementation, the board commissions an incremental purchase of products required for the next phases. Empowering the governance council to make such decisions ensures that the company is not spending their IT budget on areas that are not required in a given time line. They channel the investment where it is required to provide more tangible benefits from SOA.


Conclusion

Enterprise architecture provides the four pillars of architectural capabilities: business, application, information, and technology architecture. By systemically developing the enterprise architecture, an organization benefits from incrementally maturing their IT architecture and business architecture. Adopting SOA provides a set of best practices, guidelines, and capabilities that help an organization:

  • Develop the key alignment between the business and IT.
  • Develop a service-based application, information, and technology architecture.
  • Develop a business architecture using SOA principles.

Each pillar of enterprise architecture thus benefits from an enterprise SOA adoption.

Adopting SOA at the enterprise level is not a trivial task. It requires an overall process that provides a decision-making and management framework to foster the desired behavior in both IT and business. The SOA governance framework fits that bill: It organizes, coordinates, and harmonizes the set of activities across each architecture pillar to grow the enterprise architecture by making the most of SOA.

Resources

Learn

Get products and technologies

  • Download IBM product evaluation versions and get your hands on application development tools and middleware products from IBM® DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into SOA and web services on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=SOA and web services
ArticleID=338843
ArticleTitle=Build and refine your enterprise architecture with SOA
publish-date=09162008