When it comes to building a service-oriented architecture, British Telecom is a true veteran. The telecommunications company has spent nearly six years writing services for most of its 3,500 applications.
Naturally, the company's work has attracted a lot of press attention, since the BT is wrapping up its SOA at a time when most companies are getting started. And, what's more, the company is happy with the results.
So, when I ran across Charles Babcock's interview with the BT chief architect, George Glass at InformationWeek, I knew it'd be worth my time -- and, more importantly, your time -- to check it out.
Glass offers three major insights into how companies should approach building services:
Stop thinking about products. Software has been too product-oriented. What do you do instead? He suggests you think about building a customer-centric systems. Build generic services for customers: order-entry systems, a billing system, a provisioning system.
Think about reuse first. This may be the most important item from this article, and quite possibly from everything I've read or shared with you. The team quickly learned to ask itself one key question before it built any service:
We took designs and held them up to the light. We asked, if we built it, how much reuse would we get?
As the British say, "Brilliant!" Obvious, you might think, but it strikes me as critical to making sure you don't waste time on too small or too obscure services.
This also includes building your services for the really big deployments -- not the small ones. This will be especially important for those who choose to do bottom-up SOA, starting with small projects and building up to an enterprise-wide implementation. As Babcock puts it, it's easy to build a billing service, but if it can't handle the hundreds of thousands of bills your company needs to send out regularly, well, then, guess who's rewriting a billing service?
Offer your IT division incentives for building services that replace legacy systems. That's Glass' recommendation. I think including incentives is a fantastic idea. I'd go one step further, though. People are accustomed to being rewarded only for creating something new, but every new bit of code adds possibly unneeded complexity. If you want to keep your SOA lean and mean, offer incentives for those who reuse services.
Sandy Carter, the vice president of SOA and Websphere at IBM, told me Big Blue offered incentives when the company switched to a service-oriented architecture. In the past, developers were rewarded for holding patents on code. IBM knew if it wanted SOA to work, it had to encourage service reuse , and it put its money where its mouth was.