A significant part of getting your SOA to do what it's supposed to do is getting the people involved in the SOA to do what they're supposed to do. While you're thinking about that, consider that "Don't Tase me, bro!" was recently named the most memorable phrase of 2007. Coincidence? You be the judge.
In our last installment we looked at incentives and their role in getting people to get with the SOA program. Developing the right incentives is important in that effort, but one of the most effective strategies for getting people to do the right things is to make the right things easy to do. One of the right-est things in SOA is the systematic use of available services.
A service-oriented architecture is comprised of a network of distributed services -- chunks of self-contained, loosely coupled functionality that can be quickly and easily combined and re-combined to form a new breed of composite applications. SOA represents a far more agile alternative to developing applications the old-fashioned way, with picks and shovels and coal and steam and everybody wearing filthy overalls and getting all sweaty writing lots of new code.
There is some debate as to whether the use of services in this new kind of application development should be called "reuse," or just "use," or maybe even "sharing." Call it whatever you like, but one of the ways SOA improves agility is by making it easier to use what you already have, rather than building from scratch. The more systematic the use of available services, the more successful your SOA will be, and that increases that chances that your next holiday bonus might be something more than a calendar or a coupon for a free pizza.
Requiring development teams to seek out available services for use in projects is one strategy, but it leaves a lot of wiggle room, particularly for teams or individuals who have not entirely bought in to the SOA. And even with the most committed of teams, the need to search for and evaluate candidate services can slow things down or even discourage service use. That's why prescriptive service use is a better strategy.
The process, in a nutshell, involves shifting the evaluation and selection of services to the project planning stage of the SDLC. This requires project planners to have visibility into the service portfolio, and an understanding of what is available. The appropriate services can then be selected and assigned to the project. The development team tasked with that project is then presented with what is essentially a bill of goods that includes the services and other software assets to be used. With the right tools in place, the services and other assets can then be presented to developers directly, via the IDE, saving time, saving money, and speeding application delivery.
Prescriptive service use requires an enterprise repository to provide project planners with the necessary visibility into the service portfolio, and to integrate with developer IDEs to provide direct access to the prescribed services.
In the highly dynamic, everything-is-connected SOA environment, decisions about which services to use in a project are ultimately architectural in nature, with potential alignment repercussions. Prescriptive service use allows those decisions to be made when they will do the most good, and when they will make the greatest contribution to SOA governance efforts.
Shifting service selection decisions to a point much earlier in the SDLC also means more proactive awareness of gaps in the service portfolio. Better to learn of such gaps long before the project team wastes time looking for services that don't exist. This awareness aids in service prioritization and planning decisions, and helps to insure better alignment and business value as the SOA evolves.
We'll talk more about service prioritization and planning in future posts.