Practical Approaches for Creating a SOA-based Organization

By Majid Abai

(Back to article)

As discussed last month, a number of organizations are starting to think about implementation strategies for service oriented architecture or SOA. However, before thinking about implementation of such architecture, we should consider an approach to the whole concept in general.

In this month’s article, I’d like to focus on some practical strategic approaches to SOA before and after the implementation:

Consider SOA as a Design Approach

In his book, Service-Oriented Architecture: Concepts, Technology, and Design (Prentice Hall), Thomas Erl urges organizations to consider SOA as a distinct design approach that, much like object orientation, introduces commonly accepted principles to govern the positioning, design, and development of architectural components.

This is such a great idea. In long-term, you cannot have an organization which is half SOA and half not. The true ROI of SOA is realized when all redundancies are removed and a true shared services organization is created. So, you either embrace this approach or you do not. There is no half way.

Consider Budgeting and Responsibilities Prior to the Start of Development


  • Which organization will be responsible for maintenance of services?
  • How should budgets be allocated for development, maintenance, and future modifications of the services?
  • How should requirements from various business units be prioritized for modification and maintenance of services?
  • Whose budget should pay for infrastructure and tools utilized by all business units?
  • Should there be a centralized team responsible for quality assurance of all services (especially performance of the services) or should each project team perform this task?

    It is important to consider practical answers for the above questions (and other such questions) prior to the start of development. In order to create consistency, some organizations have created service development centers, also identified as integration competency centers; a centralized unit supervised by the enterprise architecture groups to focus on implementation, maintenance, integration and cataloging of services.

    However, other organizations have made business units or project teams responsible for implementation and maintenance of their respective services and made enterprise architecture team responsible for cataloging and integration of such services.

    Similarly, and depending on development and maintenance approach chosen, budgeting for such implementation/maintenance would fall either with the business unit or through central buckets paid by all business units. In some organizations, however, the business unit associated with the development of the service will pay for the development, where maintenance is paid by a central budget paid by all business units.

  • Consider Top-Down Planning and Bottom-Up Implementation

    Regardless of the project, I have always been an advocate of starting small, managing problems at a smaller scale, documenting lessons learned, and then expanding to other projects. The same is true for a SOA implementation: While keeping a roadmap at hand and keeping an eye on the long-term focus of the organization, take a practical (and strategic) project, implement it using SOA approach.

    After implementation, spend sometime identifying, documenting, and mitigating problems and risks encountered during this project, and then scale the approach to two or more projects.

    Consider Creating a Strategy Prior to Buying the Tools

    In many instances, we have seen many projects start by buying the tool prior to having the requirements documented. SOA is not an exception. However, this approach will be counter productive to an organization's long-term plans.

    It is important for an organization to create a three-to-five year strategy for transforming itself into a SOA-based organization including executive support, business team alignment, identification of the initial project, practical steps, governance procedures, scalability schedule, maintenance procedures, etc.—prior to identification and purchase of the tools. Identification, evaluation, and purchasing of the tools should be one of the steps in the roadmap and not the first.

    In conclusion, I like to emphasize that considering such factors while creating a strategy for transforming your organization to a SOA-based organization will save a lot of money and heart-ache for all involved. It will also allow teams to identify potential pitfalls and create best practices that could be used throughout the organization through this important journey.

    Majid Abai is president and CEO of Seena Technologies, an enterprise information management and architecture consulting firm. Majid co-authored Data Strategy (Addison-Wesley, 2005) and teaches classes in Business Intelligence and Enterprise Data Architecture at UCLA.