Does the project create business value?
Does the project have limited scope?
Would the project make a good service?
Do the team members have a good understanding of the problem domain the project addresses?
Is the project useful but not mission critical?
Considering these criteria should help you make a good decision about which project to use as a starting point. In this section, we’ll examine each criterion in greater detail.
SOA is in many ways about aligning IT with the business so that eventually there is a blurring of lines between the two. How this emerges will be very dependent on your organization and its culture. But SOA requires considerable support. It represents a new way of thinking about systems, and there are many APIs to learn. While there are free and open source tools to use as application servers, enterprise service buses, business process execution and more, many organizations will make expensive software purchases. That process can require lots of time and input from the business. The investment that the business must make in education of the team and evangelizing to the larger IT group means real time and money that initially are not spent getting something new. It is frequently viewed as a sunk cost in infrastructure that the business hopes will pay off in the long run.
For these reasons, it is important to win the business over; otherwise, the investment upon which an SOA team is dependent could dry up. The way to win the business over is to show them the money. Choose a project that will have some immediate return so that the business can remain supportive. Illustrate clearly that the real return on SOA is realized over the course of several years, as IT may be more responsive and ready to quickly address changing business needs.
The project should have limited scope. It should represent functionality that is somewhat isolated from systems that are not well known. But you will get the most out of your pilot project if it does span multiple systems. It cannot be merely a proof of concept about web services, but must be a full-blown, real-world project. Otherwise, you run the risk of underestimating scalability requirements and overall complexity.
Some practitioners recommend starting with a basic service set, and introducing the ESB and orchestration services later. In my view, you want to choose a project of limited business scope so that you have the time and clarity to simultaneously introduce the ESB initially. You don’t want to over-engineer your solution, but if you are planning to connect your work with an ESB at some point, you won’t have to revisit this. Moreover, because ESB is not standardized, products offer very different features or different means of providing certain functionality. You want to understand this central piece of your architecture early on.
Introducing SOA can lead to a lot of new APIs for developers, new application servers, new languages, and new infrastructure. It represents a new way of thinking about development. Thinking in services is different from thinking in objects. Making a switch from functional or procedural programming to object-oriented programming can take time, and represents a dramatic change for developers. I have seen Java classes in excess of 15,000 lines of code, with a single method 700 or 800 lines long. Just because you’re writing in Java and a program compiles and runs doesn’t mean it’s object-oriented, and doesn’t magically make it good. Do not underestimate the difference that services can represent for OO developers too. You need to take the time to educate everyone on the team (though not necessarily at the same time). That takes development time away. If the project has a very large scope, it might never be completed when you have so many external considerations.
You want to be able to isolate unknowns so that you can more easily identify problems during the development and quality assurance phases of the project. Be careful of choosing a product that uses brand-new products. The team will already have a number of mysteries to deal with when working with new infrastructure and APIs. Isolate your changes so that the SOA enablement work can be a leading focus. Consultants can help here.
Consider the target consumers for your initial service. You mitigate your risk by choosing something that is internal to your business, rather than customer-facing. This gives you time to build out a little infrastructure before the external world gets involved, introducing new and unanticipated issues. Internally consumed services will help you focus on implementing your first services properly, and shield you, for a time, from more advanced and complex issues such as federated security. Internal services may also represent an opportunity to gauge traffic with greater confidence.
This may be obvious; consider whether the functionality really satisfies the criteria highlighted in Defining a Service. Be careful to not have external forces choose a pilot for you if the proposed project wouldn’t actually make a good service. This happens—SOA teams get formed, and then the boss insists that the pilot must be whatever the next thing on the project list is, regardless of whether it is actually a useful service candidate. Writing services initially adds considerable complexity and expense to a project in the hopes that the benefits will outweigh such costs in the long run. If the service will never be reused or never be invoked from another platform, you might not have a very good service candidate on your hands, which means you might not realize much ROI.
Make sure that the service you choose will give you an opportunity to explore the full development life cycle. If you plan on utilizing a “start from schema” approach, for example, you want to address this head-on in your pilot, as it precipitates work surrounding the custodianship of the schemas, modifies the build process, and so forth.
It might be an overarching SOA goal of your organization to move your work in an architecturally neutral direction. This can be the case in companies with decades of legacy data tied to a specific platform. Finding a data service that wraps some central entity representations can help reduce ETL (Extract, Transform, Load) or data movement operations.
If you have subject matter experts for the given problem domain available, you can mitigate considerable risk. Introducing new systems, new software, new processes, and new problem domains at the same time that you introduce services and SOA creates a dangerous concoction. If you are working with vendors or consultants, make sure they have a background in the vertical business area you’re addressing (financial, retail, etc.).
While it is important to realize business value early in establishing an SOA, be careful not to bite off too much in the initial stages. SOA pilot projects often lose track of their deadlines, miss certain requirements, or fail altogether. Choose a project that won’t undermine your business if it takes some extra work to get it up and running as a service.
This makes service enablement of existing pain points an attractive pilot project. There is already a process or functionality in place to fall back on should it prove necessary. Obviously I am not recommending that you plan to fail, but things happen, and it’s smart to be realistic about it up-front.
The fact of the matter is that services are hard. They are hard conceptually, and they are hard practically. There is enormous complexity added to an environment to make your services portable, reusable, composable, and interoperable. They are difficult for both the business and IT to wrap their minds around.
Do some research on architectural frameworks, methodologies, and design patterns, and select some that will support you best given your environment.
Once you have completed the initial pilot, the second project, which should probably be considered a pilot extension, becomes very important. The chief goal of the pilot is to establish a foundation for SOA, understand the technical implications, and create something of value using new constraints and new strategies.
The second project provides a key opportunity to build out some of the organizational and cross-cutting concerns that SOA precipitates, such as governance (see Establishing Governance). The second pilot will, for this reason, need to have a similarly limited business scope as the initial pilot. Don’t leap into rewriting your payment infrastructure with your second SOA project. You need time to learn the behavioral patterns of your new tools and time for the education and daily reality of running the production services environment to set in.
You can also use the second project to build on your initial architecture. You may add functional or meta services, such as a rules service or security service. You may introduce BAM tools at this stage, or deepen your work with WS-Policy or security concerns in general. You might clarify and refine how you will handle service versioning, which may not have been a central focus of the pilot. You might take advantage of some more robust features of orchestration than you may not have had time or need to explore initially.