Prerequisites
Before you begin rolling out a Service-Oriented Architecture, make sure you’ve built an effective software development team. An effective team will be much more likely to succeed in bringing the following items to fruition.
Executive Support
Whether directly or indirectly, it is important that any effort to make technical architecture change is supported up the IT management chain to the executive level. Your CIO doesn’t need to know or endorse every aspect of your SOA migration strategy. However, he or she should support your effort to move the organization to an architecture that is loosely coupled, highly cohesive, standards compliant, etc.
Getting to this level of support, however, may require a bit of effort. Be prepared to make a business case for the move to SOA.
Architectural Vision
Like any other project, an SOA deployment needs motivation. However, due to the technical nature of an architectural migration, special attention needs to be paid to creating an architectural vision – a clear picture of the overall architecture after SOA deployment. The software and systems people involved need to know how the systems will work together better than before, how the development will be faster, and how maintenance will be easier. After all, your business users are not the only beneficiaries of improvements reaped from an SOA deployment. Your technical colleagues will benefit from and be impacted by such a change as well. If the current non-SOA architecture is well entrenched this can be a difficult sell, not due to the merits of the old architecture, but due to an organization’s collective resistance to change. A clear compelling architectural vision will change the perception of an SOA migration from the flavor of the month to a worthwhile effort enabling a positive long-term strategy.
SOA Center of Excellence
For any company or department-wide change to succeed, an organization must have a “go-to” group to help with adoption and education as people climb the learning curve. Designate a team (often the EAI team) as your SOA Center of Excellence and publicly charter them with the responsibility to coordinate/drive change and support those working with them. The ivory tower architectural organization will not do. The individuals on this team must work side-by-side with other developers in the organization and be involved in the implementation of SOA related projects.
Adherence to Industry Standards
One of the biggest challenges in a development organization is maintaining consistency – same process, consistent code, etc. And, compliance with internal or proprietary standards can be difficult to enforce and even harder to get people to support. However, in our world of open source and open standards, it is relatively easy to rally an organization around open standards. Furthermore, most tool vendors support the same set of specifications. For example, if you are implementing synchronous and/or asynchronous messaging, use JMS. People will support it. Vendors have implemented it. It’s hard to argue with a standards-based choice that cuts across platforms, technologies, tools, and applications. And, for the ultra-paranoid, implementations based on open standards prevent vendor lock-in and allow for application replacement if needed.
Canonical Message Format
For the widespread adoption of an SOA to succeed the services must interoperate in a scalable way. Adding a new service should be a simple extension of what is already deployed, not a rewrite of everything required by the new service. A canonical message format facilitates this expansion. There should be one (1), and only one (1), format for messages. At this moment in time XML schema defines most messaging formats. However, the same principle applies to the definition of CORBA objects, Java interfaces, or binary messages for high performance or real-time systems. The key ingredient is the standard. If a street address, for example, traveling between services A and B is not formatted exactly as a street address traveling between services C and D, then sharing address information between A or B and C or D becomes much more difficult. And, adding more systems complicates the problem (with n-squared complexity.)
Select or define a format, expand it as necessary, and stick with it.
Limited Scope Pilot Project
Implementing a limited scope pilot project provides the members of the SOA Center of Excellence with crucial first experience in the tools and technologies required to move the overall strategy forward. This pilot project should be small enough that it can be completed in less than three or four months. And, it should cut across as many of the technologies as possible. This initial learning is a key stepping-stone to being able to tackle larger SOA projects. Without such a pilot, learning the tools and technologies can overcome a project with too large of a scope, bogging it down unnecessarily. Carve out a small, yet representative and meaningful, piece of work and focus the team on bringing the architecture and tools to bear on its completion.
Opportunistic Rollout
Bringing an SOA into an existing IT infrastructure involves many systems, technical people, and business people. Making a wholesale big-bang change to a service-based architecture would be insane. Introduce the service oriented architectural concepts to projects in existing pipeline. Retrofit old point-to-point interfaces as the opportunities present themselves. If a project requires significant development to a point-to-point interface, replace it with a service-oriented implementation. Over time, you’ll make significant progress with no perceivable disruption in delivery of new features and/or applications.
While rolling out Service Oriented Architecture isn’t easy, the key success elements are quite simple.
To make an SOA rollout a success, share the vision, plan big, start small, and grow incrementally.
