Enterprise Architecture and SOA

1.0.      Introduction

SOA is an architectural style that emphasizes well-defined, loosely coupled, coarse-grained, business-centric, reusable and shared services, as well as associated infrastructure. The relationship between enterprise architecture (EA) and SOA has been a hot topic. While there is no question that these two topics are related, the question is how. Some writers and conference presenters have suggested that SOA is replacing EA, but that is not the case. What is true is that SOA brings new agility to EA practice, helps EA realize broader acceptance, and makes EA more usable. Conversely, EA provides SOA practice with enterprise views. The combination of the two can benefit both EA development and SOA practice.

2.0.      Current Enterprise Architecture Practice

The purpose of enterprise architecture is to provide a blueprint and long-term guidance for the enterprise in terms of structure and operation for its business and IT. It can help in facilitating decision making and supports enterprise modernization efforts. It can enhance collaboration and interoperation across an enterprise and can promote enterprise efficiency and effectiveness by streamlining business process and technology implementations. It enables resource sharing and increases cost efficiencies by identifying common and sharable components and services.

The challenges to current enterprise architecture practice can be organized into four categories:

             1.      Stakeholder participation
             2.      Architecture modeling
             3.      Architecture usage
             4.      Architecture maintenance and program management.

 We will discuss each category in the following sections. We will address, as well, how SOA can enable effective EA practice.

3.0.      Stakeholder Participation

One goal of EA is to break down stove-piped organizational structures and promote cross-functional collaboration. In order to achieve this goal, stakeholders must participate in EA development activities. However, traditional enterprise culture, backgrounds of people, organizational structure, and sense of priorities often limit stakeholder participation. The EA development process cannot progress well if the “right” people don’t participate. To encourage participation, the value proposition of enterprise architecture must be clearly defined and accepted.

Although EA promotes collaboration, it’s not always clear how to achieve a practical and viable enterprise model. In a large enterprise, there are many alternative ways for systems and organizations to interact .In order to facilitate effective collaboration, the target picture or work direction has to be clear, so that the stakeholders understand what they are expected to do, why they should do it, what roles they can play, and how they can collaborate with their peers. People need clear goals, objectives, work directions, effective approaches, and proven methods to make collaboration happen. In order to do this, enterprise architects and architectural approaches play critical roles.

Now, let’s see how SOA can mitigate these challenges:

First, we have to identify common services and service owners. The service owners are major stakeholders. Service consumers are stakeholders as well because they are defining service requirements. In SOA practice, the roles, responsibilities, and target picture (services) are clearly defined. Thus, it’s easier to facilitate stakeholders’ participation and to promote collaboration via common services and service infrastructure.

Due to the autonomous architectural elements of SOA, each service can be implemented as a self-sufficient component, with limited scope, so that it is manageable to a sub-organizational level. SOA is not stove-piped in nature due to the service share ability.

4.0.      Architecture Modeling

One challenge for architecture modeling is to decide the depth and breadth of architectural scope, for example, how to model “the big picture”. The second challenge is how to ensure that each audience of the model receives the information they need in a form they can understand. The third challenge is to ensure that the correct level of detail is provided to those that need it, when they need it. Too often, EA modeling efforts jump too quickly into the detailed design work, losing sight of the big picture. . In current EA practice, especially in the Federal Government sector, we see an emphasis on data gathering and artifact collection, but it lacks of emphasis on the creation of meaningful models and easy to understand conceptual abstractions. Most EA practices treat EA as an engineering process, and replace architectural approaches and methodologies with EA frameworks and modeling tools. It appears people believe that just by using an EA tool and an EA framework, and follow some widely published EA process, they will get the enterprise architecture as the end products automatically. These efforts ignored the original meaning of “architecture,” which should be a conceptual creation that gives us a well-informed and structured cohesive big picture. EA should be unique for each individual enterprise.

In many ways, architecture is a creative art. It requires artistic insight and vision in usage scenarios, structural models, business processes, and technology options for implementation. It is a living conceptual art with its own lifecycle of inception, creation, change, and maintenance. Architectural insight, intent, vision, and models guide the enterprise through continuous evolution. Currently, it is lacking of experienced enterprise architects who know how to do multi-layered conceptual models and who employ an EA framework and modeling tools as assistance for their work, instead of as the predominate mechanisms.

Now, let’s see how SOA can mitigate these challenges:

SOA can be developed iteratively with atomic service components. It is well-defined and loosely coupled. It does not require hard-wired components to create complex pictures. This solves the problems in determining depth and breadth of architecture coverage and reduces the complexity of architecture modeling.

The layered, componentized, and iterative methods for SOA modeling make architecture envisioning, planning, and modeling easier. By using layered service components, people with different skills can work in different layers. This makes more efficient use of time and provides flexibility in skills management over more traditional enterprise architecture modeling approaches.

5.0.      Architecture Usage

EA products (e.g. models, artifacts, descriptions, guidance) have to be accepted by the owning organizations before they can be put into real usage. Stakeholder participation and the value proposition of EA work are determiners of EA acceptance, as discussed above. What has also been a challenge to many organizations is to understand how to apply EA to their individual projects. People have to figure out which parts of the complex EA products are relevant to their projects and in which ways. Usually, there are gaps between EA products and the requirements for each individual project. 

Also, due to the continuously changing nature of enterprise business and technology, a flexible EA framework is necessary to incorporating changes along the way. This means the linkages between EA products and components should be identified, but should not be hardwired. The EA products should be componentized in layers so that the EA products can fit together within a flexible EA framework. Currently, EA modeling tools can definitely help, but there are limitations in their flexibility.

Now, let’s see how SOA can mitigate these challenges:

SOA can help fill the perceived gaps between existing EA products and individual projects. It can increase EA acceptance by better facilitating stakeholder participation (as discussed above), and can simplify enterprise architecture models through the use of service components and service infrastructure. These service oriented architecture models make EA implementation easier because SOA’s flexible framework is easier for local service implementation.  The functional service components can be designed to be “plug-and-play” and enable dynamic business process orchestration. SOA also facilitates iterative service development and deployment, thus enabling rapid response to continuously changing business and IT requirements.

6.0.      Architecture Maintenance and Program Management

Effective lifecycle management and IT governance policies, processes, and structures are required for effective architecture maintenance and program management. Each enterprise must define their unique requirements for lifecycle management and IT governance. These are not simple tasks, many organizations feel challenged and time consuming in getting these thorough.

Another challenge in EA program management is the availability of appropriate skills and resources. Enterprise architecture requires a very special skill set and there is no university that currently offers curricula specific to the profession of enterprise architecture. The challenge is that technically trained people tend to pay too much attention to technical details and lose the big picture, while business people tend to be lacking the required capabilities in abstraction and conceptualization. In addition to the skills that can bridge these two categories, there are breadth and depth in knowledge and artistic ability requirements for architects to have vision and insight and to be able to represent reality through representational models, as we have discussed earlier. 

Now, let’s see how SOA can mitigate these challenges:

Due to its iterative development nature, SOA-based architecture maintenance is built into the service lifecycle. Tools are developed rapidly around service lifecycle management and service governance. Although they are not quite matured yet, they can be served as a base for further development and customization to meet the unique needs from each individual enterprise. They are certainly very helpful in lifecycle management and governance practice.

SOA can ease the demanding in breadth for architecture skills, because it enables collaboration of architectural skills that are required for different service layers. Architects can be specialized in specific layers or service aspects, though we still need a few of well-rounded folks to take care the big pictures.

7.0.      Conclusion

This article described how SOA can mitigate the challenges in current EA practice. The discussions are organized into four general categories: (1) stakeholder participation, (2) architecture modeling, (3) architecture usage, and (4) architecture maintenance and program management.

SOA is becoming a mainstream architectural solution, and it is moving business and IT to an integrated new paradigm. In order to achieve its promised business value, SOA has to be business-driven and keep “the big picture” in mind. Therefore, SOA planning is closely related to enterprise architecture, which may be why some people are suggesting that SOA is replacing EA. We have argued that SOA is not replacing EA, but that SOA is an effective architecture style. SOA enhances EA development approach and methodologies; and brings new agility to EA practice. It helps EA realize a broader acceptance and makes EA practical for end-to-end enterprise solutions.

However, EA is independent of any particular architecture style, development approach, or practice mechanism. SOA, as the emerging “state of the art,” is evolving a new partnership with EA. The evolution will continue.

*This paper is published in 2007 in the IASA Enterprise Architecture - A 20 Year Retrospective.
http://www.objectwatch.com/whitepapers/IASANewsletterApril2007.pdf