In a recent study of more than 20 large enterprises, Boston Consulting Group found that as time went on and these large companies acquired an expanding arsenal of IT, far from gaining economies of scale they were in fact left with "diseconomies of complexity."
...
Traditionally architected IT systems tightly intertwine so many aspects of the business processes they automate that making even simple changes to some facet of the operation is enormously difficult. Similarly, it's difficult to get several systems -- each originally installed, potentially, by a different business unit pursuing its own tactical goals, with no coordinated planning -- to share their data or cooperate in executing complex business transactions. Either a company springs for a costly integration project or its employees cope by opening different applications on the same crowded PC screens and flipping back and forth between them.
While I like the write-up of the problem, as a somewhat experienced coder and reader of trade-rags over the years, I'm suspicious of the claim that SOA is anything close to the Silver Bullet, e.g., with SOA, "[i]n other words, monolithic gives way to mix-and-match, as Lego-like building blocks of software are recombined in almost endless combinations."
I mean, that's the line people have been using since the beginning of software-time about every vendor/design fad that's come along: structural coding and analysis, CASE, OO, Modeling, Java/.Net, BPO/BPM, Web Services, and now SOA.
It goes on to point out that several group in companies have been tempted by creating ad hoc web services to enable integration without company-wide architectural planning. Thus, down the road, the company will end up with a spaghetti web services architecture.
That's certainly true, but I don't think the answer is to go out buy a bunch of expensive SOA tools, or even start running around saying "we're SOA, yay!" The answer is for the corp. Architects to come up with a data standard and certification tests for that standard. They give this standard to all those small, ad hoc web-services-using groups, and tell them their services must comply with the standards. Then, they setup their certification tests to run against every new web service. As long as your ad hoc, or over-engineered, or however it was developed web services app passes the tests, you're good, and the company can try to dodge the spaghetti bullet.
That's one of the annoying things about corporate wide efforts lead by a vendor push for something like SOA: simply buying, installing, and using some SOA system or apps isn't going to do anything for you. The company still must decide the format the data will be in so that all these apps integrate with each other, and enforce the application's use proper use of that format. While it's easier to do the first, I'd wager most companies have down-right terrible time doing -- or even realizing they need to do -- the second.
That grip aside about SOA hoopla aside, there are good points in the article, e.g., towards the end:
[T]o make the most of the technology, companies will have to move away from centralized control toward "federated" decision-making. "This is particularly true because much of the business value of Web services and SOAs is coming from connections established across enterprises -- for example, in supply-chain or distribution-channel management processes -- where there is no single decision-maker."
That fits in well with all the "value is increasingly at the edge" that's resurfaced, e.g., on The Gillmor Gang last week. The focus in this line of thinking used to be on the at home end-user: back in the Netscape days, anyone could publish a web page, so all the sudden your neighbor was going start a web empire in his bedroom and trump the New York Times. Recently, it's moved more into the enterprise world: people aren't becoming more productive because of corporate wide initiatives and apps, they're using things like IM, weblogs, wikis, and other skunk-works (the old word for "edge computing" in the company ;>) things. The above on The Gillmor Gang has a good discussion on it.
Additionally, this article fits well into the software renovation line of thinking. Besides the agility that SOA would give you, the proponents of SOA tout it's ability to integrate all your apps together. That of course, is huge. Again, I don't think SOA on it's own is the savior for this: a corporate wide data standard is. That way, even if an app isn't SOA (I'm not sure if any app couldn't somehow be crammed into SOA shoes), it can work with the rest of your corp. apps if it complies to the data standard.
Previous Topic
