Practical Approaches for Creating a SOA-based Organization

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.