The SOA Coach

SOA: So Easy a Caveman Can Do It

2011-03-29T17:44:00.000-07:00

David Linthicum published a thought-provoking SOA article today, entitled "The Secret to SOA is Approaching the Primitive." In a few short paragraphs he makes a compelling case for swimming against the SOA stream and I wanted to echo it here.

Linthicum argues that fine-grained services are superior to coarse-grained ones (pause while libraries of SOA literature spontaneously combust) because it is "much easier to create composites" with them, allowing you to "mix and match services to live up to the exact purpose/requirements of the...application." This flies in the face of the classical belief that the value of SOA is derived from the widespread re-use of generic, course-grained services.

I agree completely. Although coarse-grained services ("GetInvoices" for example) have broad re-use potential, they lack the specificity that makes them attractive to specific business contexts. Consequently, consuming applications must refine the data set locally to make it meaningful. This requirement for consumer-side processing can often be a barrier to SOA adoption. It can also bury valuable business logic in applications that don't make their internal functions available as services. By contrast, fine-grained services (such as "GetInvoiceAmount") are implicitly tuned to deliver value with little consumer-side refinement.

As I wrote a while back, highly re-usable, coarse-grained services only account for about 20% of SOA's potential value in an enterprise. The other 80% comes from fine-grained, "long tail" services, such as the ones Linthicum describes. These are the low-level, data-oriented functions that promote widespread service composition. (Service composability delivers much more ROI than re-usability because it enables the rapid configuration of business-oriented applications, as opposed to the mass consumption of flat, contextless services.)

So don't agonize over designing massively re-usable, document-based services. Instead, expose lots of primitive, fine-grained, RPC-style (pause for collective gasp from the SOAP community) functions and compose them into more generic services over time as business cases warrant. You will service-enable more of the enterprise and evolve toward IT agility more quickly.

Hats off to Mr. Linthicum (again) for hitting the nail on the head.

Cheat Your Way to BPM Success

2010-07-21T22:07:00.000-07:00

There was a good discussion thread at the ebizQ forum today entitled, How Do You Build Solid ROI for a Company's First BPM Project? Check out the site for the full list of comments. My take is that you can't leave the first implementation to chance. Here is a full reprise of my response:

Your first BPM project is a high-stakes gamble. You have only enough bankroll for one bet, so you must win in order to be able to ante up for the next round. So how do you win at gambling? You cheat.

You stack the deck, load the dice, count the shoe, put little magnets . . . in . . . strange . . . little . . . places. You do whatever it takes to minimize chance, control variables, and bend the odds in your favor. Of course, you can't just walk into a casino and muck with the equipment--that is, unless you own the casino. You can do whatever you want in your own "house" so play the BPM game on home turf.

Rather than tackling a big, front-line business problem like order-to-cash, cut your teeth on a small IT process, such as account recertification, hardware provisioning, or project approvals. IT addressing an IT process challenge gives IT control of the variables, which improves the odds of success. This gives you access to the deck. Now stack it.

This is an ROI question, so you need to know the payoff *before* making the bet. You can't eliminate chance altogether, so base your take on the safe bet. Choose the outcome with the best odds, determine your ante, calculate the payout, then stack the deck to play that hand. (Win with two face cards rather than hitting 21. Automate a key segment of a process rather than re-engineering the whole thing.) Then deal 'em and steal 'em.

The point is, keep the first BPM project simple. Calculate the expected return up front and choose a problem domain and implementation strategy that can all but guarantee a win. There's no ROI if you don't win the bet, so avoid the long odds at all costs.

What's Next for IT? (Nothing Shocking)

2009-10-02T10:59:00.000-07:00

Peter Schoof of ebizQ recently posed an intriguing question:

"What are Enterprise IT Geeks Obsessed With Today?"

Given that SOA is becoming common practice, he says, referring to a comment made by Jason English of iTKO, what are enterprise IT folks now becoming obsessed with?

My short response, for those who consume information in bites of 140 characters or less, is cloud computing. Well, doi. A torrent of hype is raining down from the cloud and I have succeeded at stating the obvious. But before my blogging license is revoked, let me say that my answer would have been the same had the question been asked a year ago, or even five. So, for any readers who are still with me, here is how I figure IT is marching down a paved path rather than blazing a new trail. . .

An interesting pattern is unfolding, where the notion of "service" is evolving in scope and pulling IT through relatively predictable market spaces.

The '90s brought us object-oriented programming, focused on code modularization, abstraction, and reuse within software systems. (Indulge me and think of a method or class as providing a distinct "service" to its caller.) Design patterns (think Gang of Four) evolved and provided the standardization and governance that allowed loose coupling to flourish within an application's runtime environment. We built libraries of reusable "objects" that could be combined quickly into new programs. Thus, the OO phase of service evolution defined services at the code level and emphasized programming agility.

The '00s saw SOA elevate core OO tenets to a new level. Now human-relevant business functions -- built atop OO frameworks -- were the capabilities that needed to be modularized, abstracted, and reused, this time between systems. And like OO, technology standards and design best practices emerged to maximize "pluggability." The SOA phase defines services at a system level and emphasizes integration agility.

BPM has taken this further by considering entire business processes services that can be modularized, abstracted, and reused among organizational units. Again, these business processes leverage object-oriented programming logic, and sometimes SOA, for flexibility and, of course, come with their own side order of standards and best practices. The BPM phase defines services at a process level and emphasizes business function agility.

Enter the new era of service evolution, where entire business operations (benefits management, recruiting, payroll, procurement, accounts payable, CRM, call centers, software development, software testing, data storage, data processing, and so on) are being modularized, abstracted, and reused among different companies as SaaS, shared services, and cloud computing offerings. The next phase of service evolution defines services at an organizational level and emphasizes IT agilty. Business models that are not in line with IT's core value proposition are being segregated and offloaded to specialized providers who market (reuse) those services across an entire industry.

Whether it's dubbed shared services, cloud computing, outsourcing, or something else, the concept of service-oriented business models is likely to dominate IT strategy over the next several years. There is nothing shocking about this direction, though. Like its SOA and OO predecessors, it simply involves separating concerns in order to maximize efficiency. The only difference is that the "services" are being defined and managed on a different scale.

Top 10 SOA Elevator Pitches

2009-09-24T14:50:00.000-07:00

Inspired by some wacky responses to this ebizQ poll, I threw together my own (well, mostly) list of serious responses to the question it posed:

You're the CIO of a Fortune 500 company and you step into an elevator with your CEO. He asks why we should approve your seven figure SOA budget request. So what's your "elevator pitch" for SOA? Make it short and to the point -- the elevator is already rising fast.

10) Johnson in Marketing dared me to do it, sir. If you approve it I'll split it with you.

9) Pull the alarm, take CEO's wallet in the confusion, and escape through roof hatch.

8) You mean that needs your approval?

7) Our vendor already gave us SOA. We just need the money so we can turn it on.

6) Burst into tears and admit your grandmother needs the money for a hip operation.

5) Either you can approve this now or I can ask your successor next year.

4) We actually already have an SOA. We need this money to unwind all the JBOWS.

3) Never discuss SOA with a CEO (wink -> Jessica Ann Mola)

2) No, I had no idea "SOA" meant "sexually transmitted disease" in Dutch, Mr. Van Der Winkle. . .so is that a yes? (nod -> Edwin van Asch)

1) Would it help if I told you we were building a cloud?

Have any of your own? I'd love to hear them!

SOA for Short Busers

2009-09-20T18:50:00.000-07:00

Know someone who still doesn't get it? SOA has been on the scene for nearly a decade, but yes, we still need to be able to break it down for newbies. Joe McKendrick recently gave props to Alex Kriegel for his suggestion of using the US Post Office as a metaphor for SOA. To paraphrase, Kriegel offers that the USPS is to SOA as courier services are to JBOWS architecture. Couriers may be fast and reliable but are comparatively expensive and difficult to scale. I really like the idea of using the USPS as a metaphor for SOA, but I would take the comparison in a slightly different direction.

The problem with JBOWS is that it produces a proliferation of poorly designed, one-off service interfaces. In other words, it is point-to-point SOA -- the same old bad integration habits in more fashionable clothing. So the issue is not SOA versus JBOWS per se; it is SOA versus conventional, point-to-point architecture. Or, distilled even further, loose coupling versus tight coupling. My only criticism of Kriegel is that his metaphor emphasizes the inner workings of the USPS and courier services rather than the interactions they have with external entities. Here is how I would humbly spin his metaphor to cover a little bit more ground. . .

If the USPS were a point-to-point system, each of us would have a separate mailbox in our front yard for every destination we would ever send a letter to. Each box would have a slot that fed a long pipe that opened to an inbox at the other end -- like those mysterious old vacuum tubes at drive-thru bank stalls. And no two pipes would ever cross. If you wanted to send a letter to Aunt Hilda in Tucumcari you would have to plan a few months ahead and ask the Post Office to build a mail pipe between your house and hers. Of course, they would contract it out to the lowest bidder and you would get whatever that particular team at that particular time was savvy at building -- and supporting. Repeat this process for every letter you send or receive with a unique To or From address and you'd end up with a house-sized mail sucking contraption straight out of a Dr. Seuss book. Oh yes, and, naturally, the thing would only get bigger and scarier over time because no one would know how to remove unused mailboxes from the giant wad of tangled suck pipes.

Thankfully, we, the endpoints of the mail system, only need to manage our way around one mailbox each. As long as it conforms to simple addressing and postage rules, we can throw anything in there and the USPS will take care of the routing and delivery. It's simple, easy to adopt and use, efficient (be nice), standards-based, centrally managed, and keeps mail senders and receivers loosely coupled for scalability and maintainability. SOA simply does for data providers and consumers what the postal service does for mail senders and receivers: simplify to one interface per participant, decouple the endpoints, and standardize the logistics in between. Bada-bing.

The telephone system works as a similar metaphor too. Instead of clusters of vacuum powered mail pipes rising out of our front yards, though, we would connect ourselves to each other with tin cans and strings -- one string and two cans for everyone we know. What a mess. We don't stand for point-to-point architecture at home. Why should we stand for it at the office?

Service Reuse? Whatever

2009-09-16T10:30:00.000-07:00

I stumbled upon a couple good articles on the (imaginary) value of reuse in SOA recently:

Less focus on reuse is good for SOA by David Linthicum
There is more to services than re-use by Brenda Michelson

David points out that "agility requires that you address the architecture holistically" and that focusing too much on reuse causes SOA to devolve from an architectural effort into a programming one.

Brenda takes a complementary stance, stating that the value of good (she use the term "modular") service design transcends reuse by dampening the effects of change.

I share their sentiment and chimed in on the topic not too long ago as well:

Long Tail SOA and the Mythology of Reuse

My view is that basing SOA on reuse only modernizes 20% of IT and, thus, does not yield agility. Reusable services are, by definition, popular ("mainstream"), and tend to orbit around relatively static business data (employees, customers, vendors, suppliers, etc.). It is wise to service enable this data because of its ubiquity, and doing so can facilitate quick wins that demonstrate concrete ROI and advance SOA initiatives, but that well runs dry pretty quickly.

The other 80% of service opportunities reside at the Long Tail of IT -- that area of swirling chaos beyond core ERP functions that produced rogue app server colonies and mountains of point-to-point connections in the first place. This is where polished data is stripped from the monoliths and sliced, merged, lumped, and otherwise sullied in innumerable ways to support specific, one-off business needs. There is little reuse here but it is where raw data is decorated with business context and intelligence. This is where business is really conducted and this is where SOA is really needed.

To focus only on service reuse is to ignore the fact that our customers need services specifically tailored to their business units in order to stay competitive. SOA is about responding quickly to changing business appetites, not forcing everyone to eat from the same menu.

How to Ruin a SOA Program and Bankrupt IT (Re-Post)

2009-09-12T10:05:00.000-07:00

I have received a lot of valuable feedback on the Bottom Line SOA paper and would like to address one topic that has come up frequently, and that is whether simply choosing SOA over point-to-point (P2P) integration is enough to achieve agility.

I explained in my article that a fundamental characteristic of SOA is its linear cost curve and contrasted it with P2P's non-linear cost curve. The "bottom line" is that SOA inherently keeps costs linear, predictable, and scalable over the long haul while the cost of P2P accelerates uncontrollably. The net effect is that service-oriented networks are enterprise assets that appreciate in value as they grow, while P2P networks are depreciating liabilities. SOA, by its nature, produces positive ROI. P2P, by its nature, produces negative ROI. Therefore, if you embrace SOA and forsake P2P you should be set, right? Wrong.

To be sure, taking a stand against traditional P2P integration is a big leap in the right direction. However, it is one thing to say you are service-oriented and quite another to be service-oriented. And if you're talking the talk but not walking the walk you can end up in worse shape than if you had opted against SOA in the first place.

SOA often requires a paradigm shift -- a shift in attitudes and thinking away from project-based, short-term objectives toward enterprise-based, long-term objectives. When the people doing the talking are not the ones doing the walking, the mental shift may not occur everywhere it needs to. This can produce a situation where an organization has obtained sponsorship and funding for an SOA program but lacks the discipline to adhere to its core principles during implementation. When SOA has been promised but the implementers are only comfortable with P2P, the result is often point-based SOA.

From a financial standpoint, point-based SOA combines the short-term cost hikes of SOA with the long-term, accelerating cost accumulation of P2P. What is left is an overly complex network of tightly-coupled services linked together through physical connections and proprietary interfaces. (Imagine a network of web services in which each service can be used by only one consumer.)

Relating this phenomenon back to the Bottom Line analysis, the resulting cost curve (P-SOA) resembles the P2P cost curve. The only difference is that it has been shifted upward by a coefficient that represents the extra infrastructure costs of SOA. In the end, point-based SOA costs more than traditional P2P integration and yields no gain in IT flexibility or agility.

IT organizations that are adept at selling SOA at the podium need to also have the tactical ability to execute on SOA missions. This requires shared vision, passion, and deep commitment to the fundamental principles of SOA at all levels of the IT ranks. Companies that have difficulty producing this cultural unity are at a distinct disadvantage in ever realizing the benefits of SOA. In fact, they may be better off just ignoring the hype and walking away.

The Economics of Agility (Reprise)

2009-09-06T15:35:00.000-07:00

SOA isn't dead, but it may be hanging on by a thread, as if on life support in the ICU wing of IT Community Hospital. Meanwhile, the concepts of enterprise agility, lean IT, flexible architecture, business enablement, and shared services are as popular as ever, giving thrust to newer concepts like cloud computing. These ideals underpin SOA, so why the bad rap? In a word--scratch that--in an acronym, ROI.

I wrote a white paper not too long ago that compares the fundamental economics of SOA and classic point-to-point architecture. This analysis has helped me succeed at SOA, particularly with gaining (and keeping) trust and funding. I have seen SOA deliver on its promises, but only when ROI is tracked carefully at every stage. The fact that SOA has lost much of its hype while its core values remain top IT priorities is evidence to me that we SOA practitioners have done a collectively poor job of demonstrating real, quantifiable value to our businesses.

Our businesses valued SOA at one time and still value agility. SOA continues to mature and remains a powerful catalyst for agility. We just need to empathize with the business mindset and attack SOA from an economic perspective rather than a technological one. (By the way, SOA does not imply heavy investments in new technology. In many cases it can work simply by shifting attitudes and business practices.) There has been a sudden resurgence of interest in my original paper--a sign that folks may be re-evaluating their SOA strategies rather than abandoning them--so I thought I would reintroduce the topic as a refresher and offer a link to the PDF. Enjoy!

Bottom Line SOA: The Economics of Agility