OKAY, I have been far too lazy in reporting back various experiences with clients as I discuss SOA. Very recently on a cold day and snowy in Michigan I met with a client who was singularly focused on what to do next. As I would mention motivations and rationales, he would politely communicate that we are convinced on the value and benefits of SOA we simply want to know how to get started or stated differently what have successful clients done to get stated.
So armed with that I articulated that there are different entry points and ways to get started but which one you select often depends on what will work in your culture (that is, your maturity in various aspects of software engineering), your appetite for change, funding models and of equal importance your business goals or motivations.
So I explained the six motivations should be understood so that we can determine the business value desired. That is, it is ill advised to pursue SOA as an end goal instead we pursue SOA as a software engineering best practice, as part of an enterprise architecture approach, part of an IT strategy or as part of a transformational effort (more on this in the future).
Six motivations must be understood because each will cause a different set of actions:
1. Flexibility2. Improved business process (e.g., cycle times, optimization, etc.)3. Revenue increase4. Cost reduction5. Risk and compliance6. Integration So if flexibility is to be something other than a platitude versus a durable statement that has a business and IT impact then one must be specific as to how they will know they have achieved flexibility when it occurs. Does flexibility include reuse? When we look at the SOA solution stack which (see http://www.ibm.com/developerworks/library/ar-archtemp/) which describes various layers in any SOA solution, we see potential reuse at several stages: services sharing, infrastructure sharing, etc. If flexibility is a motivation then we are embarking on a journey, an endeavor that will not be complete with one project but something that will require a program. It requires we address IT and SOA governance.
Improving the business process that involves 3rd party suppliers is an often seen motivation. Typically this involves extranets and is focused on using Web services as both an enabling standard and technology.
For some companies we see a desire to take their legacy assets (e.g., telephony functionality or reservation system) and make this functionality (i.e., services) available for 3rd party application providers or other consumers who build composite applications or sell the services as a part of their capability, resulting in a new revenue stream for the service provider.
Cost reduction often cannot be fully achieved without reuse of services. So often we are looking at using shared services as a way of retiring applications thereby reducing the total cost of ownership of the portfolio. In many cases one can achieve this goal without SOA, but at some point SOA may be necessary as the approach for re-structuring parts of the application and IT portfolio.
Risk and compliance can sometimes translate to exposing services to expose aggregated data or the orchestration of services in a workflow to address compliance.
Integration is a primary motivator for many organizations looking to adopt SOA. Integration has its own obvious benefits but in addition, the choice of applying SOA to integration also inevitably requires the organization decide if this will be a technology implementation or a transformational implementation. Organizations choosing the technology implementation may falsely conclude that they will achieve SOA benefits of reuse simply with the implementation of the technology where in reality they have solely remedied an integration issue. Getting the infrastructure to be shared (i.e. reused) across multiple lines of business (i.e. consumers) requires addressing more than tecnology, organization change management issues become apparent as an example.
SOA is not binary, there are different types of implementation, solutions and motivations. If one does not clearly define the motivation then its quite likely the result will not be met and SOA benefits will become another of IT broken promises.
So how do organizations get started? Of course the devil is in the details, but we have seen five entry points:
1. Technology. Examples are where the organization adopts one or more Web services standards or a product in the context of a sandbox to introduce the technology into the organization. Often there is also a project which can take advantage of the technology. This could also be the introduction of information as a service. For example, the aggregation of data from multiple sources might be best achieved using a service.
2. Business process management. In this example, the focus could be on improving or optimizing or developing automation for one or more business processes.
3. Connectivity. Integrating services across multiple applications inside and outside the enterprise for one or more defined business objectives
4. IT transformation. In some cases organizations have a "burning platform" which means that the technology or the application in its current state will not be able to meet foreseen business requirements presently and in the foreseeable future. Or the problem could be that IT requires a major improvement in its application delivery capabilities or it could simply be that IT costs have spiraled to unacceptable levels dictating IT simplification, IT optimization and other changes. Within this entry point multiple business motivations may be at play. Organizations could be trying to do more for less where they then examine how to increase the amount of reuse.
5. Business transformation. This is a case where due to regulatory changes, a public embarrassment, lack of sticky customers, changes of business models or whatever the business motivation, there is a need to do business and It transformation in parallel. Often this focuses attention on specific business scenarios that require addressing whether its people centered or process centered.
In addition we then discussed several case studies and I introduced the notion of a maturity model for providing a route map, a guide.[Read More]
Client Insights on APIs and Services
with Tags: to X