Where to start with my SOA implementation?
SOA is not hype any more. There are too many successful implementations and software vendors claiming large reference deployments. However, you cannot simply buy SOA. You have to scout your personal path into a service oriented IT and process landscape on your own, based on the existing landscape and business requirements. This article describes briefly some best practices, CIOs and chief architects reporting from their approach to SOA and the selection of infrastructure products.
SOA is not a product but an architecture paradigm
Unfortunately SOA cannot be purchased like a shrink-wrapped packaged application. A service oriented architecture’s intention is actually to integrate an existing application and IT infrastructure in a way that enables you to roll out new business processes and composite applications. SOA is not about buying all business logic out-of the box and investing a little bit in the individual customization. In fact, it is the exact opposite: Considering your core business logic as a differentiator to your competitors; you’d rather like to leverage these past investments and re-compose it into a new agile way depending on your today’s demand.
Start SOA as a CIO initiative
Execute your SOA initiative as a high awareness CIO subject and do not try to delegate it to the in-house application development, the IT infrastructure group, or even an external consulting company. Finally, all these departments have to agree on the same understanding of the concepts and terminology of your individual SOA landscape. Ensuring interoperability between all of them requires moderation by the CIO office. Do not underestimate the effort of this change management process.
Realistically, SOA is just one initiative among other CIO initiatives. Sourcing strategies for Software, Hardware and Outsourcing Services are major CIO responsibilities as well. Most of these products or services are commodities like databases, operating systems and application servers. However, the infrastructure components which are helpful for your SOA architecture are still emerging and are subject to innovations. Thus, an intense discussion between the technical architects, the CIO and the purchasing department is required. Your preferred vendor may not be the best supplier for your SOA infrastructure.
Every CIO usually leverages KPI metrics, benchmarks, maturity models and management instruments such as balanced scorecards. Apply the same success metrics to your SOA initiative as you do for all other large projects. Meanwhile some vendors (such as Software AG) offer a predefined set of SOA KPIs as part of the SOA delivery methodology. The SOA Governance tool can instantaneously report your organizational and technological maturity and the status of the SOA deployment.
Do not underestimate the relation of your SOA initiative to the other CIO initiatives. Take a master data management (MDM) initiative as an example where you would like to consolidate duplets and outdated customer records across all applications. A corporate data model compliant to an XML-Schema is a prerequisite for this activity. The same XML-Schema should should be applied to services on the ESB as part of your SOA initiative. Ideally the MDM product and the ESB share this meta data via a corporate SOA Governance Repository.
Show the business value of your SOA implementation
A service landscape has a lot in common with the free economic market. A service is successful, if it is bound soon and extensively to many consumers such as BPM systems or composite applications. At the same time, it does not make any sense to create services that already exist or that nobody will use.
Further on, consumers must have the opportunity to demand a new service or an orchestration of a high-value business service, instead of an existing service not meeting their demands any more. The CIO office must find the right balance between free demand/supply dynamic and rigid SOA governance rules planning a certain portfolio of services in your enterprise. This balance may start on the “communist” style rigid planning side and move over time to the “democratic” free dynamic side.
Especially the loosely coupled SOA needs strong policies
Establish policies for life-cycle management, security, quality, SLAs and the requirement negotiation of all artifacts in your service landscape, no matter if it is a legacy adapter, web service, business process, service orchestration or composite application. Many large organizations have profound experience with the consistent modeling of business processes. Start to relate the creation of new artifacts with the already existing and the emerging models such as process models or MOF compliant descriptions of data and activities. Following these guidelines, the orchestration of multiple fine-granular technical services into valuable business services, consumed by a BPM system is a straight forward approach.
Beyond these design-time policies, plan to install an enforcement of run-time tools as a next step. Meanwhile there are some dedicated software products for this kind of SOA Governance such as Software AG’s CentraSite Governance Edition and Amberpoint SOA Management products.
Finally, many different tools in the design-time tool-chain and run-time infrastructure have to exchange their meta-data. In the absence of any mature standard of meta data exchange, the good message is that many vendors realized this demand and started to form communities around SOA management such as the CentraSite Community hosted here on InfoQ.
CIO’s bottom Line on SOA policies is: While you are proclaiming the democracy on the service portfolio, behave like a totalitarian ruler on the policies!
Encourage architects and engineers to make experiments
Do not try to purchase a single SOA Infrastructure which may provide all functionality you need. Even if your preferred Software supplier provides a mature ESB, be aware that SOA is an architecture paradigm and not a standard product such as a database or an application server. High-End ESBs might be overkill at the beginning, while being appropriate later in some cases. Larger organizations might deploy a co-existence of one commercial high-end ESB and a number of lightweight open source ESBs. Similar strategies are common for the usage of commercial J2EE applications server in the computing center versus the deployment of Jboss in subsidiaries. This ensures that developer who need basic interaction with your Service landscape are not stuck in overwhelming functionality they never need. The more tailored your infrastructure is to the local requirement, the more important is the compliance of all infrastructure to some basic and mature Meta-data interoperability. Both UDDI3 and JAXR are the common standard of interoperability between both high-end and lightweight ESBs as well as the SOA Governance Repository.
Select the SOA infrastructure due to your business scenario
Take one step back and have a look at your current infrastructure. Is there already a message oriented middleware (MOM)? In most cases many dedicated queues are configured for specific purposes on a MOM. This is complex and does not allow orchestrating fine grained technical services into high-level business services as it is possible in an ESB. Have a look at the business scenario and find out if this example matters to your personal SOA path. Maybe you do not need an ESB initially. In the following you will see three typical business scenario patterns and the corresponding product selection:
I. Processes across organizations and application boundaries
If you run an ERP system, some Java or .Net Applications and other packaged applications, you probably have more service than you expected. Historical Mainframe applications or M&A activities increase the complexity even more. Retrieving and understanding hundreds of services can be much simpler with a SOA Repository/Registry. The business value can simply be driven by a process landscape beyond the domain boundaries of these existing applications. The first stepsare usually a Legacy-Adapter Framework and a BPM system. Users might find the automated process as extensions to their existing user interfaces or in the UI provided by the BPM product. No ESB or Composite Application Framework is initially required.
II. Composite Applications
Composite applications are not necessarily process oriented. They maybe ad-hoc task-oriented and run without a BPM system. The business value could be the efficiency of a call-center agent accessing multiple applications across your SOA landscape via the same simple composite application in a unified user experience. Start your SOA initiative in this case with the selection of a composite application framework, which can effectively compose loosely coupled service calls into an ad-hoc business task such as the change of a customer address or the retrieval of an order status. This kind of business value will create significant demand of services provided out of the existing application silos. Start with a Legacy adapter framework and the composite application framework in this case. The rest will be driven by the demand/supply dynamic of the corporate service market.
III. B2B SOA
Many companies in the manufacturing industry exchange a lot of data in B2B EDI communication. However, maintaining changes or extending this communication to smaller suppliers is very difficulty and costly. The business value could be to move this part of an B2B communication which is subject to most changes from EDI into a flexible B2B SOA communication. In this case you should first look for an ESB supporting B2B trading capabilities. The selected SOA Repository/Registry should be able to public a subset of your corporate meta directly to your suppliers outside the firewall. No BPM or Composite Application Framework is initially required.
