Start Making Sense

Bad habits are awfully hard to break. For us, a mess or an assignment inevitably fills the available space or time. Even if we’ve got the time, we still typically put off writing that report or cleaning our desk until we absolutely must. Obviously after too many 1:30am finishes, you’d think we’d finally start turning over a new leaf.

Similarly, IT vendors still haven’t shaken their habit of spouting grandiose promises.

You’d think that after several years of “IT doesn’t matter” bashing, we’d finally junk the vision thing and start talking about the mundane problems that we really solve.

Here are just a couple examples from press releases culled during the past week. We’ve protected the guilty, because with everybody equally complicit, we didn’t want to fairly or unfairly single anyone out.

“[Blank] announced a partnership and the completion of SOA governance integration between [blank], the company’s award-winning Service-Oriented Architecture governance solution, and [blank], a set of products designed to govern and accelerate Web service integrations spanning security and identity domains without expensive and inflexible programming.” In a follow-up conversation, they characterized this as an “end- to-end” solution.

Translation: An industry standard UDDI registry and a run-time XML gateway link via industry standard SOAP messages. The registry, which is used for defining policy, updates the gateway, which filters web services messages at run time. Because the link is an industry standard, there’s nothing unique being offered except the promise that both vendors will theoretically not point fingers when it comes to questioning whose adherence to standards is more correct. And by the way, their so-called end-to-end solution stops short of tying in systems management frameworks, meaning that infrastructure hiccups remain unaddressed.

“[Blank’s] SOA Governance solution will help customers establish tailored decision rights in the organization and implement the policy, measurement and control mechanisms necessary to carry out those decisions… [Blank] is making business flexibility through SOA governance a reality for our customers.”

From the statement, you’d think the press release unveils some dramatic breakthroughs or visions covering SOA governance. In fact, it references a choice of 40 existing products, a new “governance plug-in” to a software development process framework, plus several new products (data modeling and a systems management change configuration database) that are general-purpose offerings that perform many other useful tasks besides SOA governance.

The goodies bundled into this press release solve real problems. But the only relevant part of the announcement was the governance plug in. Hardly a grand new governance offering, although it will address a narrow but useful piece of the puzzle.

Announcements like these, which otherwise sound like they’re ushering in new paradigms, in actuality, solve modest, mundane, point problems. To paraphrase Seinfeld, we’d respond, “As if there’s anything wrong with that.”

So we’re wondering why tech vendors continue pushing the vision thing. CFO’s are far more likely to approve purchases if they actually address problems they can understand rather than forcing them to drink Kool Aid.

Hey folks, we solve some real problems. Would it kill us to stop claiming otherwise?

Blood Brain Barrier

Once upon a time, maintaining service levels was a simple yet difficult matter. At least you knew who was responsible for tuning databases, monitoring infrastructure, and safeguarding access control. The hard part of course was getting everything working as promised.

Service-related issues have traditionally been dealt with piecemeal, at the perimeter, data center, and inside application and database silos. Even after web applications exposed databases to the outside world, the action that mattered was confined (1) to the application inside the firewall, as the domain of security specialists or DBAs, or (2) out there in the cloud, where it was the service provider’s problem.

You had, in effect, a barrier between the circulatory and nervous systems where interaction, and responsibility for it, was carefully proscribed.

Life isn’t as simple anymore. With services eroding the silos demarcating internal applications from one another, not to mention the outside world, it’s growing difficult to delineate where the system admin’s responsibility leaves off and the software developer or process owner kicks in. In a Services-Oriented Architecture (SOA), key aspects of business logic are often intertwined with service level.

Consider an order fulfillment process. The customer’s procurement system triggers a series of events, culminating in a requirement to receive confirmation from you, the supplier. In so doing, the customer system fires a request to your order processing system, which in turn triggers an orchestrated process involving inventory checks, approval workflows (where warranted), queries to logistics providers, followed by final acknowledgment. When you guarantee a platinum-level partner or customer priority service, you are implicitly promising that your infrastructure will deliver at a specified performance level.

In such a scenario, who’s responsible for ensuring that the request is genuine, comes from an approved customer or partner, and requires response within a given timeframe? We’ll understand if you’re drawing a blank.

When silos of functionality break down, so does division of labor. System admins, charged with infrastructure health and perimeter protection, are over their head when considering the subtleties of contractual service guarantees. Likewise, the software and process folks are understandably edgy when it comes to banking on infrastructure issues outside their control.

Not surprisingly, the market for governance solutions reflects the current organizational disconnect. Systems management providers like BMC, CA, HP and IBM are accustomed to calling on systems admins or operations, while SOA run-time governance upstarts like Actional (now part of Sonic), AmberPoint, and SOA Software speak to software shops.

There’s been a bit of consolidation. HP’s acquisition of Talking Blocks a couple years back and IBM’s more recent acquisition of Cyanea, provide hints that the artificial boundaries between infrastructure and service management markets may eventually dissolve.

But that won’t happen before customer organizations overcome cultural inertia.

When you first deploy a handful of services in an SOA pilot, you can readily babysit them yourself. When you ramp up to dozen services or more, you need a mechanism to enforce policy at run time. And once you really get serious about SOA deployment, that’s when you need better-coupled infrastructure management.

Nope, you won’t want to breach the blood-brain barrier outright because your perimeter must remain sacrosanct. But you’ll need some way to improve circulation.

Connecting the Dots

Simplify, automate, integrate. First coined by Andersen Consulting during the heyday of MRP II in the late 1980s, it provided a consultants vision of what was possible if you integrated systems to eliminate the overlap rampant throughout your organization.

Since then, the words may have changed, but the goals haven’t.

Remember client/server? It was supposed to “downsize” the mainframe, simplify cryptic green screen applications and embellish them with local functionality so you didn’t have to constantly bounce back to the mainframe. Then came n-tier web applications, whose thin clients eliminated the localized complexity introduced by client/server. And when Y2K found organizations replacing their enterprise systems, EAI (enterprise application integration) was supposed to simplify integration with standard adapters and a centralized hub for brokering the connections.

Then services-oriented architectures (SOAs) emerged with a stripped-down architecture that simplified all the things that EAI was supposed to do.

Admittedly, the act of publishing services represented a dramatic breakthrough in simplifying systems integration. But you can’t simply publish services and expect anybody to connect to them. If you take SOA seriously, you’ll still need another layer to route and mediate services with business, performance, and security policy. Some might call that adding a layer of complexity, but without it, you’ll wind up with the same jumble of spaghetti that you had when you integrating systems the traditional way.

In part, this explains the rising popularity of business process management (BPM).

If your organization has a specific pain point – such as a field rep or call center that is unable to commit an order because they cannot see inventory positions – maybe the solution isn’t devising an inventory service or integrating inventory system transactions with your order entry or CRM system.

Maybe all you need is a screen that windows in the appropriate data, or a workflow to ensure that whenever you get an order of a specific size, a formal approval process is triggered to ensure that committing such a big order doesn’t violate company policy.

That’s what BPM can do. In some cases, it can prove a much simpler alternative to transaction integration.

Consequently, we weren’t all that surprised about the buzz surrounding BEA’s acquisition of Fuego earlier this week. BEA was filling in a blank in their product portfolio to keep pace with IBM and Oracle, snaring one of the most promising pure plays in the process.

But most of all, it reveals that vendors must acknowledge the demand for the kind of simplicity they’ve been promising all these years. What might look robust to a software architect may appear positively intimidating to business analysts bent on avoiding programming-intensive solutions.

Of course, BPM won’t be the last word in simplicity. For starters, it’s not mutually exclusive with SOA. And like SOA, if you get serious about BPM, you’ll need to add a management layer to ensure that all those processes remain aligned with the business.

Nothing comes for free, least of all anything that promises simplicity. Even if all you have to do is connect the icons, at some point, you’ll eventually have to invest the effort to connect the dots.