Sometimes - many times, actually - standards aren't enough. Just ask AT&T.
AT&T learned the hard way that there's an "A" in SOA and it stands for architecture - as in a cohesive plan. But at the beginning, AT&T just focused on building Web services. It went from having "a bunch of disconnected, incoherent integration interfaces, to having a bunch of disconnected, incoherent standards-based' interfaces," Forrester Research analyst Randy Heffner told IT Business Insider. In SOA-speak, they call this JBOWS - just a bunch of Web services, and it's widely considered poor form, although it does have defenders.
Well, I suppose that's one way to eliminate integration. Technically. Kind of.
We've had years to acclimate to SOA now. While there was at first a lot of talk about SOA and integration, the accepted wisdom is that it's not a way to handle integration - although it still seems to me that fewer application integration projects may be a side effect.
For instance, Joe McKendrick recently pointed out many states - including my home state of Kentucky - are using SOA to modernize legacy applications. By using services to access legacy applications, these states are making progress on integrating tax systems, McKendrick explains. In California, the savings achieved by using SOA to modernize legacy apps is expected to bring in an additional $1 billion a year through efficiencies and better data analytics.
So where does that leave SOA? It's still a smart and efficient way to design your systems if you're focused on business processes and governance rather than technology processes, the IT Business Insider article notes.
That means focusing on developing services for frequently used business processes, such as credit checking, the article suggests. Frank Braski, who manages IT Applications Services for Aflac, contends those processes can be defined and modeled around seven concepts:
While SOA may simplify application development and legacy modernization, that does not mean it is simple or easy. The article points out there are a lot of pitfalls - including copying and pasting to reuse services. IBM's Sandy Carter also cautions that IT will need to constantly check to see if services still meet business requirements.
My favorite thing about this article is that it brings back that old Legos metaphor so often used to explain SOA - but this time, there's a twist.
Good Lego designers learn there are a common set of patterns that can be applied to different building problems, the piece notes. Services can be as simple as a Lego brick, the article notes, but anybody can put together two bricks. It's the patterns and how you use them that make the difference between just a bunch of Legos and a truly impressive Lego edifice.