November 11th, 2009

Why IT can't seem to deliver measurable productivity

Posted by Joe McKendrick @ 10:15 am

Categories: Business ROI, Links, Management, SOA Surveys and Research

Tags: Information Technology, Janne, Strategy, Management, Joe McKendrick

Are your investments in IT bearing measurable results? Or are the benefits more “feels-right” types of results? Perhaps IT can’t deliver measurable productivity because the measurements are wrong.

Perhaps IT can’t deliver measurable productivity because the measurements are wrong

Every time I’ve spoken to a CIO and IT manager over the past decade, one question I always ask is if he or she has been able to measure the results of programs, be it service oriented architecture, CRM, Web-to-host, what have you.  And, I have to admit, I rarely hear measurable numbers — it’s usually anecdotal evidence, such as speedier processing, or positive end-user or customer feedback.

Don’t blame the CIOs, though — it’s just that the benefits of IT are inherently difficult to quantify at any high level. In this vein, Janne Korhonen just published an interesting piece over at ebizQ, explaining why it’s so hard to measure the productivity impact of information technology.

Janne quotes MIT’s Erik Brynjolfsson, who in 1993 published a landmark paper on why the productivity impacts of IT is so hard to measure: 1) measurement error due to use of conventional productivity-measurement approaches; 2) time lags in IT payoffs; 3) localized optimization; and 4) lack of explicit measures of the value of information.

We don’t seem to have come too far in the 16 years since Brynjolfsson published that analysis — at least in Janne’s opinion. He delves into Brynjolfsson’s four challenges in some detail. For example, he notes that when it comes to measurement errors — caused by outmoded ideas about constitutes productivity — he calls for “rigorous new means to measure IT productivity and output are needed to account for IT’s role in innovation and new value creation, commensurable with IT-enabled efficiency.” IT’s contribution to “operational improvements, new capabilities, new products and new markets” — long underestimated — is a good place to start.

As discussed here at this blogsite, there are benefits and gains that are either tough to capture, or tough to tie directly back to a particular IT initiative. “Business agility” is a classic example — how do you measure business agility?  This is the benefit touted for service oriented architecture — how much agility is being delivered by an SOA initiative, versus other systems? The businesses at the forefront of SOA tend to be at the forefront of other advanced management practices as well.

Then there’s the whole matter of oversell, companies pouring money into IT products and services that may be, on the whole, unnecessary or overkill. Or worse yet, end up as shelfware. You don’t need to be a productivity expert to see the waste there. So you have the combined storm of hundred of thousands of dollars being spent on something for results that, if measured, will be measured against archaic productivity standards. Will cloud breath clarity into this confusion?  Probably not.

It should be noted that Brynjolfsson hasn’t been entirely pessimistic on the ability of IT to deliver business success since that 1993 paper. More recently, he and MIT’s Andrew McAfee published data that shows IT making a big difference at a macro level. They observed that industries that made the greatest investments in IT during the 1990s have become the most competitive. “On average,” they said, “the whole U.S. economy has become more ‘Schumpeterian’ since the mid-1990s. [Joseph Schumpeter coined the term "creative destruction" in 1942] What’s more, these changes have been greatest in the industries that buy the most software and computer hardware.”

Again, it’s more than pouring money into products. McAfee and Brynjolfsson state that even with a lot of IT, “both innovation and replication require a combination of leadership and insight from executives. Take innovation: Many companies use IT to capture huge amounts of data from their operations, but relatively few have been able to use this data creatively.”

And it takes perceptive management to identify the technology solutions that will make a difference, and be able to effectively measure the impact of those solutions.  As Janne put it:

“Not all IT projects are productive. They may even be detrimental to the business, but misaligned incentive schemes and other structures sustain non-optimal IT decision-making with predominantly short-term planning horizon and focus on operational and cost efficiency. IT investments should be judged by their overall bottom line impact, including not only cost reductions and efficiency gains but also the indirect impact that IT has on increasing business effectiveness.”

The bottom line is that there has never been an expectation that IT would be solely responsible for a company’s rise or fall. Adroit management, supported by the right IT tools, makes the difference. A company that smartly and innovatively leverages its IT in new and creative ways will move to the head of the pack. And, thanks to IT, you don’t need a workforce of thousands to do so. And we need to measure these changes in more holistic ways.

November 6th, 2009

Event processing means more than 'speeding up' existing systems

Posted by Joe McKendrick @ 8:43 am

Categories: Business ROI, Data managemetnt, Enterprise Architecture, Event processing, Management, SOA Events, SOA Surveys and Research, business process management

Tags: Event, Service-Oriented Architecture (SOA), Web Services, Pricing, Strategy, Application Integration, Middleware, Enterprise Software, Software, Marketing

Complex event processing — now made possible by service-oriented architecture principles — represents the next stage of business intelligence. However, much work needs to be done to reach this capability.

Complex event processing requires a different mindset and skills

A ebizQ’s latest SOA in Action conference, I had the opportunity to moderate a session with Gartner’s Roy Schulte, CalTech’s Dr. Mani Chandy (CalTech), and IBM’s Frank Chisolm in an informative discussion about applying event processing as a strategy for businesses seeking to remain competitive in the years ahead.

However, Roy cautioned, event processing capabilities don’t just automatically pop up, even among companies with the most advanced BI infratstructures. “The way you get your systems to be more smart fast and agile is by having the systems designed correctly, and in most cases that means more use of the event processing design methodology,” he says.  “You can’t just take a conventionally designed system and just speed it up to accomplish the goals that people want to do.”

While the technology now exists to build CEP, the methodology requires a different mindset among companies. “The limitation that we have today is that there are not enough people around who understand how to design systems that operate in this fashion,” Roy says. “They don’t understand continuoius intelligence or complex event processing.”

Complex event processing requires continuous streams of information from multiple sources. The good news is that CEP need not be so complex, and, in fact, over the next few years, systems that sense and respond to events will be as commonplace as business intelligence systems are today.

Mani, considered one of the early visionaries of complex event processing, said the “PC-cubed” formula (three Ps and three Cs) will drive CEP forward over the next few years:

• Price – The price of managing data sources will continue to drop.
• Pervasiveness – Sensors, such as mobile phones, have become pervasive.
• Performance – “Enterprises have access to immense computing power that can be harnessed through event processing,” Mani says. And now, “parallel, distributed, and cloud computing create ideal environments for event processing.”

• Celerity - “Businesses and consumers demand swift action,” Mani points out. “You expect to be notified immediately if your plane is late.”
• Connectedness – The world is more interconnected. Your company may need to respond immediately to an earthquake in China, a flood in India. Event processing applications help detect events all over the globe.”
• Complexity – “Businesses have become more complex, and expect IT to help with increasingly complex problems.”

As if laying out the case for complex event processing as “PC” doesn’t clarify enough, Mani also explained how a mnemonic — A, E, I, O, U (but not sometimes Y) — describes the CEP phenomenon:

• A — Adaptability: “The event pattern has two advantages, one is loose coupling for application integration, and the other is sense and response,” Mani said. “App integration because producers and consumers are coupled in a loose way without knowing about each other. Its easy to add or change the producers and consumers of a system. With the sense and respond aspect, an example is scheduling railroad crews — a complex problem, a sense-and-response problem.  Because unscheduled events happen all the time, smart railroads are using event processing to adapt.”
• E  — Exceptions: “Computers have to analyze torrents of data to extract nuggets,” said Mani. “These nuggets are the events that require a response. A characteristic of smart people and smart systems is that they mange by exception.. they perform continuing operations effectively, bit they continue to detect and respond exceptional situations. Event processing helps separate the critical from non-critical.”
• I  — Instrimentation: “Successful businesses manage exceptional events successfully,” according to Mani. “Event processing is used to instrument and monitor the exception and the normal. You will see a rapid rise in business instrumentation and event processing for to improvement of business activity in the next decade.”
• O — Outside: “1960s-90s enterprise IT dealt with mainly IT inside the enterprise. Now the enterprise is responding the events externally,” said Mani. “The enterprise monitors actions by the government, its competitors, its suppliers, and its best customers.  The ability to sense and respond to events out side the enterprise using event processing is a significant competitive advantage.”
• U — Unanticipated events: “Enterprises develop event process applications to handle certain types of that they expect, and must also deal with conditions that they don’t expect,” Mani explained. “Any significant deviations are detected by an event processing application which then sends information about this deviation to appropriate people before the analysis.”

Dr. Mani Chandy and Roy Schulte have just puiblished a new book on the subject, entitled “Event Processing - Designing IT Systems for Agile Companies.”

November 4th, 2009

Gartner: 10 reasons why both sides of the SOA debate have it wrong

Posted by Joe McKendrick @ 9:34 am

Categories: Business ROI, Enterprise Architecture, Management, SOA Events, SOA Surveys and Research, Web Services, business process management

Tags: Gartner Inc., SOA, Service-Oriented Architecture (SOA), Web Services, Middleware, Enterprise Software, Software, Joe McKendrick

Pro-SOA view: SOA is the greatest thing since sliced bread.

Anti-SOA view: SOA is toast.

SOA moderate view: Let’s just worry about baking service orientation into our business processes where we can.

I just had the pleasure of hosting a Webcast keynote with Gartner’s Yefim Natis over at the ebizQ “SOA in Action’ event, and Yefim did a great job of popping the myths around SOA — not only among the naysayers, but among the over-optimistic SOA proponents as well. Instead, Yefim urges a balanced middle course with SOA, with a serious emphasis on what it can do for the business.

Here are the 10 most common myths — promulgated by both SOA “fanatics” as well as naysayers — that need to be put to rest (no pun intended):

SOA Fanatic Myth #1 - Services were invented in the IT department and are spreading out to the business. This myth assumes that SOA architects and designers “will be bringing solutions to the business that the business itself couldn’t invent,” Yefim says. However, he observes, “encapsulated functions have existed in business forever. This is how business is structured.” Instead, SOA is about improving the “ability of software designers and software architects to model the real world better. Software is not bringing the solution to the business, its better understanding the business.”

SOA Fanatic Myth #2 - SOA applications are assembled from pre-built components. “SOA is not a Lego game,” Yefim says. “Although service oriented systems indeed include encapsulated components, or services, they also include clients, batch components which are not service oriented, and include legacy systems that need to be connected to.”

SOA Fanatic Myth #3 - Sharing or reusing application logic is the main benefit of SOA. “In reality, a successful environment will have reuse of about 30%, so that is a ballpark number where you should feel good about your level of reuse,” Yefim says. “If that’s the case, it means many organizations will have less than 30% — so reuse is not the primary benefit, although it is one of the benefits of service oriented architecture. There are many other things, such a making your internal architecture more manageable, having greater extensibility, and applications that function a lot better when they are service oriented.”

SOA Fanatic Myth #4 - SOA eliminates the need for application integration. No matter how effective your SOA infrastructure, you’re still going to need enterprise application integration, Yefim says. What SOA does do is “introduce a consistency to the architecture, as well as tools and standards that help application integration.”

SOA Fanatic Myth #5 - SOA reduces the cost of IT. It may help reduce IT costs in the log run, but early on, “investment in SOA costs in fact costs more,” Yefim says. “Not because SOA is more complex, but just because when you do something new, you have to understand new approach, you have to train people, you have to buy new tools — and that all is costs.” What SOA does do is “shift the costs, distribute the costs differently.”

Yefim also took the occasion to refute some of the negative things also being said about SOA as well. Here the top five naysayer myths about SOA:

SOA Naysayer Myth #1 — SOA introduces new complications and new problems. “That might be true, depending on what you were doing before,” Yefim says. “After all, complications and problems are all relative to prior experience.”  However, he points out, “most issues that have to do with deploying and establishing service-oriented systems are not issues of SOA; they’re issues of distributed computing, or of modern grid based computing networks.”  Without SOA, he says, companies would “probably be facing the same complications and issues.” At least SOA provides a more consistent approach to tackling these problems.

SOA Naysayer Myth #2 — SOA is nothing new, it’s hype, it’s taking old wine and trying to sell it in a new bottle. SOA is merely a set of coarse-grained remote procedure calls (RPCs). SOA builds upon earlier models of distributed computing and RPCs, but it’s something different, Yefim points out. “SOA is intended to address a business topology of the business functionality of the application, whereas RPCs  were intended to simply distribute an application.”

SOA Naysayer Myth #3 — SOA is doomed because Web services don’t work well enough. This widely held misconception is based on the view that SOA is entirely based on SOAP. “There’s nothing in common between the two, yet people confuse SOA with SOAP. SOA is not about Web services — Web services is one of the ways of establishing connectivity between the clients and the services of SOA.”

SOA Naysayer Myth #4 — SOA is hard to sell because the business can’t see the benefits. This is probably true for basic-level SOA, but as more companies move into advanced SOA, business benefits will become more apparent, Yefim says. “After all, SOA is an architecture, and the business sees software as a means to a goal, rather than the goal in itself.’ However, as SOA begins to support new initiatives such as event-driven processing, business awareness may grow. “Event-driven SOA has very important components to it that allow direct benefits, clear benefits to business operations, to any business that wants to gain control over its overall IT information environment or wants to build situation awareness.” Event-driven SOA, Yefim adds, “is the foundation for business activity monitoring, business intelligence, situational awareness. All of these directly serve business.”

SOA Naysayer Myth #5 — SOA is obsolete, and its time to move on. Indeed, the industry is probably ready for a new round of buzzwords, Yefim says. “There’s no intrigue anymore in basic SOA.  We know how to do it, it’s not talked about as much as before.” But, he asks, “What are you going to move on to? The only alternatives you’re going to find to SOA are going to be advanced forms of SOA.” [See SOA Nay-sayer Myth #4, above...]

November 2nd, 2009

Analyst: seven ways to get SOA back on track

Posted by Joe McKendrick @ 7:26 pm

Categories: Management, SOA Events, SOA Surveys and Research

Tags: SOA, Randy Heffner, Service-Oriented Architecture (SOA), Web Services, Middleware, Enterprise Software, Software, Joe McKendrick

SOA is still being held back by perceptions that the methodology is a set of IT best practices, versus business best practices.

In a recent presentation, Forrester Research’s Randy Heffner provided an analysis of what’s holding SOA back, and what it takes to move it forward. I had the opportunity to join Randy in an informative session on what should make SOA tick.

Randy cited Forrester survey data that showed general acceptance of SOA principles within a majority of enterprises, but many pockets of trouble. About 18% to 25% of Forrester’s survey group said they are still “struggling with SOA, and they’re not going to expand further until they figure it out.”

What are they trying to figure out? Randy points out that “SOA is a diificult and complex initiative,” and to succeed requires “reframing from some of the broad messages you hear in the industry.”  Companies struggle with SOA, he explains, because, first, “they treat SOA as a technology” rather than a business transformation. Second, they “treat SOA as objects and components,” and third, “they over-focus on reuse,” which is but one of the benefits.

Randy suggests seven “fixes” that can help get SOA off the narrow technology project track and onto the business services track:

Fix 1 — Use SOA to create a business model. “Use SOA based bus services to insert a layer of simplicity around the business where you most need it.”

Fix 2 — Build service portfolios, not service libraries. “The library view can be a very haphazard, amnesic way to manage services. Service developers will forget what services are out there…. We’re trying to leverage projects, and put them within this broader strategic context withoin our porfolio.”

Fix 3 — Adopt a “street-level” strategy to address both short and long-term SOA. “We need to move away from this big-bang approach to SOA.” A street-level strategy is adaptable to any shifts in the business — such as hard versus good economic times, Randy adds.

Fix 4 — Avoid the reuse trap. “Yes, reuse is a good thing, and you will see benefits. But it’s not all about reuse, it’s about the right design, and reuse is the side effect that should be happening as you’re doing good design.”

Fix 5 — Adopt a variety of SOA funding strategies. You can get SOA money in and of itself, get SOA funding for solutions that use SOA, or get it through training or R&D programs. Most SOA funding comes from solutions-oriented projects, Randy says.

Fix 6 — Do SOA governance. If a company was event doing just one or two of the 12 best governance best practices covered in Forrester surveys, it “was correlated with higher satisfaction with SOA,” Randy says. “Even a little SOA governance leads to satisfaction.”

Fix 7 — Do more SOA governance. “If you’re doing SOA right, SOA is far from dead,” Randy says.”And SOA governance will keep it on track.”

October 26th, 2009

Survey: cloud interest grows triple-fold; cost may not be main factor

Posted by Joe McKendrick @ 3:00 am

Categories: Business ROI, Management, SOA Surveys and Research, Web 2.0-Enterprise 2.0, cloud computing

Tags: Avanade, Survey, Cloud Computing, Virtualization, Hardware, Joe McKendrick

Everyone figures that companies are buying into cloud to save money. A new survey says otherwise. But why are companies adopting cloud?

A new study (PDF link) commissioned by Avanade shows a 320% increase over the past nine months in respondents reporting that they are testing or planning to implement cloud computing. Avanade claims this is the first time a survey has documented a global embrace of cloud computing in the enterprise.

The study also found that while companies are moving toward cloud computing, there is little support for cloud-only models (just five percent of respondents utilize only cloud computing). Rather, most companies are using a combination of cloud and internally owned systems, or hybrid approach.

Okay, the survey confirms what we’ve been seeing anecdotally. That is, there’s been a huge uptick in cloud interest. And apparently, this has been taking place during an economic downturn. But here’s where it gets interesting: Only 13% said the onset of a tougher economy helped push them toward the cloud. A majority, 58%, say economic conditions had nothing to do with it.

While Avanade didn’t seem to read anything into this, another observer, Paul Miller, thought this finding was a real eye-opener, suggesting that contrary to what everyone assumes, cloud computing decisions are not being driven by cost-cutting needs:

“Also interesting was the relatively small impact of the economic situation upon Cloud adoption, with only 13% suggesting it had ‘helped’ adoption plans and 58% reporting ‘no effect.’ In my conversations with Nick Carr and others, there’s been an underlying presumption (on my part, as well as theirs) that cost-saving arguments with respect to Cloud Computing would prove persuasive and compelling.  It would appear not. This would suggest, of course, that enterprise adopters are taking to the Cloud for reasons other than the budget sheet…”

If it isn’t its low entry costs, then why is cloud computing so popular? Avanade says half of the companies surveyed that have migrated to cloud computing technologies use it to “manage and deliver business applications such as customer relationship management (CRM) and human resources (HR) services.” Forty‐six percent of respondents are also using cloud computing for data storage.

Speaking of greater flexibility and agility, the Avanade survey suggests that the service model is taking over as the prevailing IT value proposition. As Avanade puts it, the “online services model is beginning to fundamentally change how IT services are consumed and provisioned in large organizations. More than half of respondents report that they are currently using Software as a Service applications. In the United States, that number increases to more than two-thirds (68 percent).”

And many of these deployments are internal cloud. Avanade says that globally, “there is a 2:1 ratio of respondents who prefer SaaS delivered internally (or as private services) versus from third-party service providers. There is an even greater dissparity in the United States, with a 4:1 ratio in favor of internal SaaS deployments.”

October 21st, 2009

Gartner leaves SOA off 'top ten' list - again

Posted by Joe McKendrick @ 1:26 pm

Categories: Data managemetnt, SOA Surveys and Research, Web 2.0-Enterprise 2.0, cloud computing

Tags: Enterprise Mashup, Gartner Inc., SOA, Service-Oriented Architecture (SOA), Web Services, Middleware, Enterprise Software, Software, Joe McKendrick

Gartner just issued its Top 10 Technology list for the year ahead, and guess what’s missing? Once again, service oriented architecture got sacked by the sages of Stamford.

SOA proponents, however, can take cold comfort that just as was the case last year, SOA is the underpinning foundation and enabler of many of the Top 10 technologies. Cloud computing?  You need a foundation to deliver those services across firewalls. Cloud also sucks in Web oriented architecture and enterprise mashups — prime SOA territory. Advanced analytics? They won’t be so advanced if data doesn’t get pulled out of organizational and system silos. Client computing? Enterprise mashups, anyone?  And, hey, where is event processing?

October 14th, 2009

How event driven architecture changes the SOA service flow

Posted by Joe McKendrick @ 7:14 am

Categories: Event processing, Links, SOA Surveys and Research, Web Services, business process management

Tags: SOA, Service-Oriented Architecture (SOA), Web Services, Middleware, Enterprise Software, Software, Joe McKendrick

Does event driven architecture (EDA) represent the next phase of SOA?  This is a subject of continuing debate, but Udi Dahan makes the case for EDA as the next logical stage of SOA. In a recent post, he connected the dots between SOA and EDA, suggesting that EDA will shift the inherent nature of SOA.

Dahan makes his case thusly: SOA is currently based on a “commonly used request/response communication pattern of service consumer to service provider in SOA,” in which the consumer delivers the command, and the provider service responds accordingly. “Commands are often named in imperative, present-tense form—for example, ‘update customer’ and ‘cancel order.’”

With EDA, this relationship gets reversed, he points out:

“In EDA… Consumers do not initiate communication in EDA; instead, they receive events that are produced by emitters. The communication is also inherently unidirectional; emitters do not depend on any response from consumers to continue performing their work.”

Developing an architectural approach that employs both SOA and EDA principles will go a long way toward better so-called “business-IT” alignment, Dahan observes. The fusing of the two approaches may be the key. Either approach alone won’t do it. As Dahan illustrates:

“Architects can explain to the business the ramifications of their architectural decisions in ways that the business can understand—’There might be a couple of seconds during which these two bits of data are not in sync. Is that a problem?’—and the answer to those kinds of question is used to iterate the architecture, so as to bring it into better alignment with the business.”

SOA and EDA have been moving closer in recent years, as companies start to understand the value of event processing to ongoing operations and opportunities.

October 9th, 2009

Gartner: You want cloud? You need SOA first

Posted by Joe McKendrick @ 8:07 am

Categories: Enterprise Architecture, Links, Management, SOA Events, SOA Surveys and Research, Web 2.0-Enterprise 2.0, cloud computing

Tags: Gartner Inc., SOA, Service-Oriented Architecture (SOA), Web Services, Middleware, Enterprise Software, Software, Joe McKendrick

In a new report, Gartner analyst Yefim Natis is quoted as saying that the success of cloud computing hinges on having good service oriented architecture underneath. “Prepare for the cloud by developing SOA skills,” Natis says. “The arrival of cloud as an option for the delivery of business applications could finally cement SOA into the IT mainstream,” he adds.

Natis urges enterprise IT shops to continue investing in service-oriented architecture skills and initiatives if they are to be able to take full advantage of the emergence of the cloud infrastructure. SOA may eventually become the standard way by which applications are accessed through a cloud service, he adds. This will also propel adoption of private clouds, contained with the firewall.

We’ve been banging the SOA-Cloud drum for years here at this blogspot (e.g., here in 2005; here, here, and here in 2007), and it’s good to see respected analysts also taking up the theme. SOA is evolving into the underlying enabler for private clouds, to the point where they almost can be considered one in the same. SOA has often been a tough sell. The good news is that the business readily grasps — and even likes — the idea of private and public clouds as a way to better organize and manage computing resources.

September 29th, 2009

SOA, event driven architecture will be in smart systems everywhere

Posted by Joe McKendrick @ 7:33 pm

Categories: Event processing, Links, SOA Surveys and Research, business process management

Tags: SOA, EDA, Service-Oriented Architecture (SOA), EAI, Web Services, Middleware, Enterprise Software, Software, Joe McKendrick

In recent years, we’ve been hearing a lot about the rise of event-driven architecture (EDA), and how this will factor into SOA efforts. This combination may form the foundation of emerging “smart systems.”

CalTech’s Dr. K. Mani Chandy, one of the pioneers of EDA, and author of Event Processing: Designing IT Systems for Agile Companies, says we will be surrounded by SOA and EDA in the years to come. In a new interview with Peter Schooff, Chandy explains:

“I see a great opportunity for both [SOA and EDA] in the next, I say, 20 years starting now. …I really see them being used in all aspects of daily life. I mean management of food, water, energy, health, security and logistics… And what we call smart systems. A lot of talk about smart systems and smart system architectures are fundamentally based on principles from EDA and SOA. And the benefits of these event-driven architecture applications will be directly visible to the business, they’ll be directly visible to the customer and so I think acceptance of these applications and demand for these applications will grow virally and so I see a great future for them.”

Chandy has a formula that illustrates how and why demand for EDA will grow in enterprises in the years to come: “PC-cubed,” for push for ‘price, pervasiveness, performance” accompanied by demand from “connectedness, celerity, and complexity.” The need to process complex events will not only arise in large enterprises, but also in the consumer space as well. “We see really complex events where you’re trying to detect patterns of stock prices and relate them to commodity prices. But you also see complex events in consumer applications where you’d like to know when a given item becomes cheap with one vendor versus another,” Chandy points out.

EDA has been around in various forms since the 1970s, Chandy explained. It’s roots can be traced back to enterprise application integration and sense and response systems. “EDA appeared in the 1970s in message queuing systems and later in enterprise service buses, and this is the EAI ‘parent,’” he said. “The other ‘parent’ is sense and response. In the last decade, many companies have developed sense and respond applications in finance particularly in trading. Now however, sense and response systems are being used in every aspect of life including management of water, food, energy, security, health and so on.”

September 22nd, 2009

Services or subtasks? SOA and BPM may mean the same thing

Posted by Joe McKendrick @ 2:51 pm

Categories: Management, SOA Surveys and Research, business process management

Tags: Business Process, BPM, SOA, Service-Oriented Architecture (SOA), Operational Planning, Business Process Automation, Web Services, Enterprise Software, Middleware, Strategy

We’ve been debating on these pages whether SOA and business process management go together, or if they’re actually two very different disciplines.

Jason Bloomberg recently provided his take on the SOA-BPM discussion, saying that SOA and BPM are structurally the same. They may, in fact, be an example of “process isomorphism.”

Jason is kind enough to provide a definition of isomorphism (”a mathematical concept that expresses a relationship between two concepts that are structurally identical but may differ in their respective implementations”). In an SOA context, process isomorphism means, hypothetically, “if you were to model a business process, and as a separate exercise, model the composition of services that implements that process, where those two models have the same structure, then they would be isomorphic.”

Looking at SOA-BPM this way, then helps to establish a common language between business and IT, Jason points out:

“The business folks can be talking about processes, and the IT folks can be talking about SOBAs, and at a certain level, they’re talking about the same thing… If process specialists want to think of Business Services as process subtasks, then they can go right ahead. Similarly, if technical implementers prefer to think of business processes as being compositions of Services, that’s fine too. And best of all, when the BPM team draws the process specification on one white board and the SOA team draws the composition specification on another, the two diagrams will look exactly alike. If that’s not business/IT alignment, then what is?”

Jason has hit upon something here, in that the perceived “rift” between SOA and BPM is more a product of semantics than actually structural differences between the two disciplines. SOA provides a collection of services that can be mapped to business processes as required.

September 22nd, 2009

Enterprise mashup market to increase tenfold over next five years

Posted by Joe McKendrick @ 9:28 am

Categories: Links, SOA Surveys and Research, Web 2.0-Enterprise 2.0, Web Services, cloud computing

Tags: Enterprise Mashup, SOA, Service-Oriented Architecture (SOA), Web Services, Enterprise Software, Software, Joe McKendrick

A new report from Business Insights predicts that the enterprise mashup market, worth around $161 million in 2008, will expand more than tenfold to $1.74 billion by 2013.

About 33% of companies now use enterprise mashups, Business Insights says.

The catalyst for the enterprise mashup market will be SOA — Business Insights puts the SOA platform market at about $1.4 billion in 2008, which will double in size, to about $2.77 billion by 2014.

It’s interesting that the enterprise mashup market, which currently is about 11% the size of the overall SOA platform market, will soon be 63% the size, or getting close to comparable. This is huge for the front-end part of the equation, if these numbers pan out. But does it make sense?

September 15th, 2009

ESBs are patterns, not products

Posted by Joe McKendrick @ 9:16 am

Categories: Enterprise Architecture, Links, SOA Surveys and Research, Standards Watch, Web Services

Tags: Enterprise Service Bus, SOA, Service-Oriented Architecture (SOA), Web Services, Middleware, EAI, Enterprise Software, Software, Joe McKendrick

Thomas Rischbeck, a contributor to Thomas Erl’s SOA Design Patterns, wants to clear the air on some of  the confusion and controversy that has been associated with enterprise service buses (ESBs).

From day one, ESBs have suffered from lack of standards

That is, he writes in a new article, “The essence of an ESB can be much more easily grasped by talking about the ESB as a pattern: the pattern of applying an intermediate proxy to service communication. The ESB pattern is about performing integration tasks and adding value to client-service communication in an SOA – all completely transparent to the participants.”

The confusion with ESBs date back to their very start, when vendors took the lead with pushing these products out to market. But they rushed things because they were under the gun, Thomas says:

“Faced with market domination by IBM, [message-oriented middleware vendors were the first to jumpstart the ESB concept with the aim of developing a unique selling proposition. They added Web service and EAI capabilities on top of existing message broker capabilities, and with analyst support coined the term ESB. ESB was positioned as a low-cost alternative to EAI and panacea for all integration needs – tell-tale signs of hype. Unfortunately, the standards community was too late to get on the bandwagon. In the absence of standards guidance and the lack of a clear definition, each vendor interpreted ESB to its advantage. As a result, comparing ESBs is like comparing apples and oranges. No two products are compatible today with severe consequences (in terms of vendor lock-in) for end users.”

As a result of all this vendor confusion and FUD-creation, ESBs mean a lot of different things to different people. Instead of thinking of ESBs in terms of what vendors say they are, Thomas urges thinking of ESBs as a pattern — as he puts it, “the pattern of applying an intermediate proxy to service communication.”

He provides a more detailed definition for the ESB pattern:

“The ESB pattern is about performing integration tasks and adding value to client-service communication in an SOA – all completely transparent to the participants. …The ESB is a compound pattern that pulls together many enablement and enforcement capabilities that come in handy to the SOA practitioner. Reliable Messaging, Message Manipulation, Data Format and Data Model Transformation as well as Protocol Bridging are just some sub-patterns examples under the ESB umbrella. These are all enablement aspects where the ESB allows communication between endpoints not possible otherwise.”

There are two major alternatives to ESBs, Thomas adds — either application servers everywhere or nothing at all.  While doable, this makes efforts to support delivery of services more complicated than they are, he says. Of course, there are many SOA proponents that say ESBs are essentially useless appendages that do more harm than good in the long run. Perhaps elevating the discussion to more vendor-neutral territory will help clarify what, if any, roles ESBs could play in tomorrow’s SOAs.

September 11th, 2009

Forrester's Randy Heffner: only one percent turned off by SOA so far

Posted by Joe McKendrick @ 3:15 pm

Categories: Business ROI, Management, SOA Events, SOA Surveys and Research

Tags: SOA, Forrester Research Inc., Randy, Service-Oriented Architecture (SOA), Web Services, Middleware, Enterprise Software, Software, Joe McKendrick

The problem with service oriented architecture is that people have been thinking about it too narrowly.  Randy Heffner, VP and analyst with Forrester Research, says all too often, SOA has tended to be pigeonholed “as a technology, the next thing in line after objects, and components; and all about reuse and just about connecting between applications on the wire.

View SOA from a business design, not technology perspective

“These are all very small ways to view SOA,” he feels. “What’s much more important is to view it from a design perspective.”

I recently had the opportunity to sit down with Randy in a podcast (MP3 link here) hosted over at ebizQ site. Among other things, Randy talked about a report Forrester issued last spring in the wake of Anne Thomas Manes’ “SOA is Dead” proclamation — titled, appropriately enough, “SOA is Far From Dead, But It Should Be Buried.”

What struck me was the fact that once an organization gets going with SOA, it will tend to stick with it for the long haul. In fact, as Forrester’s statistics bear out, only a minute fraction will give up and walk away from SOA altogether. “There’s a group of folks that struggle, but most importantly, there’s only about one percent of SOA users who say, it’s provided little or no benefit and we’re cutting back,” Randy says.

In fact, Forrester’s study uncovered deep and wide support for SOA, Randy says. “The data shows that SOA is very much alive and well and very much adding value,” he explains. “Not perfectly in the sense that there are still folks that struggle, because SOA is not an easy thing. But I think a lot of the struggling with SOA comes from …is some of the misguided ways that people view SOA.” As noted above, the misguided thinking is too-narrow thinking about what SOA can accomplish.

“By the end of this year, 75% of the global 2000, that’s folks with 20,000 or more employees, say that they’ll be using SOA,” Randy continues. “When we asked, ‘Are you satisfied?’ roughly 25% says that SOA has provided most or all of the benefits that they expected. There’s another 30 to 40% that said, ‘It’s provided less than we expected, but still enough benefit that we’re expanding our use of SOA.’”

What do the 25% moving full force into SOA have in common? “They’re treating SOA as a business-design concept,” Randy says. “That sets a whole different perspective on how you view the kinds of services that you’re building, the methods that you put around it.”

An element of the business-design view of SOA that doesn’t get enough attention, Randy feels, is service portfolio management, which is an important piece of governance.  “A lot of folks say ‘SOA is all about a service library, just let projects create what services they need to, and drop them in a library, and then people can search, discover something that’s there that they might be able to use.’  Well, that’s a very haphazard kind of way to go about your business.”

Instead, approaching SOA through service portfolio management emphasizes services created to address business capabilities. “You know what business you’re in.  You should be creating a coherent portfolio of business capabilities that are embodied in your SOA services. And, hence, service portfolio management is a much stronger approach to building a collection of services than a service library approach.”

Listen to or download the 11:54 podcast below:

Download file

Check out the full transcript of the podcast interview.

September 4th, 2009

Enterprise architecture pitfalls: the obvious, and beyond the obvious

Posted by Joe McKendrick @ 3:49 pm

Categories: Enterprise Architecture, Links, Management, SOA Surveys and Research

Tags: Electronic Arts Inc., Enterprise Architecture, Strategy, Management, Joe McKendrick

Brenda Michelson’s latest blog post over at ebizQ employs a very 2.0-ish approach to gathering management advice. Brenda, a thought-leader in enterprise architecture, looked at Gartner’s latest list of the Top 10 EA Pitfalls, which included these points:

• Selecting the wrong lead architect to manage the process
• Not engaging businesspeople
• Not measuring and communicating the impact
• Not establishing effective EA governance early
• Not spending enough time on communications

Ho-hum.. You get the picture. Gartner’s suggestions are blindingly obvious. Brenda decided such a list needs a little more pizazz and real-world perspective. So she hashtagged (#eapitfall) a query out to her Twitter followers: Show us some “Real EA pitfalls.”

A couple of good ones that surfaced included “Example EA Pitfall: Running behind a project team waving a red flag” (courtesy of @Cybersal) or EAs turning into “standards cops” (courtesy of @gleganza).

Here are a few more from Brenda’s crowdsourced list of EA Pitfalls (all stated within 140 characters, of course):

“Most developers have no clue what project plans even say.Why bother to read them. 90% done, 2 years remaining on 6m project” (@mcgoverntheory)

“Example EA pitfall - developers persuade stakeholders that EA guidelines are unnecessary redtape” (@richardveryard)

“Example EA pitfall - corporate acquisition of enterprise application package preempts EA activity” (@richardveryard)

“Add to EA pitfalls: Start/Shutdown Pattern: as in: ‘we’re on our 6th attempt to create #EA in last decade’” (@aleksb6)

“EA Code Trap: “Our EA will build the shared/common applications/frameworks” <- not EA, it’s EAppDev” (@aleksb6)

“Not applying design mind to study enterprise behavior and only creating static un-integrated artifacts.” (@sboray)

“Thinking one-size-fits-all is the ideal for all scenarios (Jeanne Ross’ ‘Unification’ operating model)-makes EAs standards cops” (@gleganza)

“EA Pitfall - EA is TOGAF or Zachman or another method/framework. It is about delivering real business value” (@malcolmlowe)

“EA Pitfall - EA is 80% architecture 20% communication/buy-in #eapitfall. It is more like 20% architecture 80% communication/buy-in” (@malcomlowe)

September 1st, 2009

Another view: cloud not ready to take on SOA heavy lifting

Posted by Joe McKendrick @ 8:29 am

Categories: General, Links, SOA Surveys and Research, cloud computing

Tags: Cloud Computing, SOA, Service-Oriented Architecture (SOA), Web Services, Middleware, Enterprise Software, Software, Joe McKendrick

Anne Thomas Manes penned a thoughtful response to my recent post on “Cloud: the SOA we always wanted, but never had?” Anne agrees with my premise that cloud computing will boost the viability of SOA in business contexts, but takes issue with points I made about cloud finally delivering some long-sought SOA promises — including being understood by the business, being technology agnostic, necessitating provider-consumer contracts, or building trust between service providers and consumers. It’s too soon to make these assertions, she states:

As far as I can tell, cloud computing is none of these things. It should be. But cloud is too nascent for such assertions. Besides, in order to achieve these characteristics in cloud-based systems, organizations have to 1- design them that way, and 2- develop the contracts and trust described. You won’t achieve these characteristics automagically just by deploying a system to EC2, Force.com, or some other cloud provider.

I agree with Anne that we’re in the early stages of this paradigm, and the current cloud model for external-provided services (such as EC2) doesn’t address deep integration issues. However, with SOA as the foundation of private cloud implementations, we are more likely to see many of the above-mentioned promises of SOA finally being realized.

My colleague Phil Wainewright also provides some interesting thoughts on private clouds in his latest post. For enterprises, the future may lie in virtual private clouds, or “computing that operates within a public cloud but which uses virtual private networking to give individual enterprises the ability to mask off a portion of the public cloud under their own delegated control and management…  so that enterprises can begin to harness the benefits of cloud computing without having to expose their entire existing infrastructure to the public cloud in one fell swoop.”

Clearly the future of SOA as well. Stay tuned.

August 27th, 2009

Cloud: the SOA we always wanted, but never had?

Posted by Joe McKendrick @ 1:19 pm

Categories: Business ROI, Links, Management, SOA Events, SOA Surveys and Research, Vendor Watch, Web 2.0-Enterprise 2.0, business process management, cloud computing

Tags: SOA, IT Costs Cloud, Service-Oriented Architecture (SOA), Web Services, Middleware, Enterprise Software, Software, Joe McKendrick

Is cloud computing — in which services are produced and consumed across entities — paving the way for a massive wave of service oriented architecture adoption across businesses?

‘Cloud is SOA done right’

I recently had the opportunity to join a lively panel discussion led by Phil Wainewright to ruminate over this question, and we came to a general conclusion that cloud, indeed, is making SOA an easier sell to businesses. The consensus seemed to be that cloud is helping to boost the advantages promised by service orientation to a firmer business footing.

Phil and I were joined by David Bressler, principal architect with Progress Software, and Ed Horst, vice president of product strategy for AmberPoint. (Listen to the 45-minute interactive panel discussion here, read the full transcript here.)

I know many of you will correctly point out that cloud and SOA are different entities, with SOA focusing on the architecture and cloud on delivery of services. But consider the ways cloud is turbo-charging SOA. In some cases, SOA proponents have been struggling for years to get things moving in the right direction, and cloud is providing some new oomph and vitality to the effort:

• Cloud (as SOA should be) is well understand, and often demanded, by the business
• Cloud (as SOA should be) is platform, language, and technology agnostic
• Cloud (as SOA should) provides greater visibility and transparency to actual IT costs
• Cloud (as SOA should) necessitates binding contracts between service providers and consumers
• Cloud (as SOA should be) is based on trust between service providers and consumers
• Cloud (as SOA should) originates from business requirements

As Phil — who has been tracking developments in this space since launching LooselyCoupled.com almost a decade ago — put it, “Cloud is SOA done right.”

The panel kicked off with a discussion of the advantages cloud brings to the table, including service functionality across firewalls, more rapid delivery of information technology, and greater opportunities for integration. However, Phil pondered whether these are all the benefits that SOA was supposed to deliver.

Dave observed that cloud enables these advantages “through a way that allows you to use external providers to jump start that. “By doing that, it becomes much more component driven.”  Plus, actual costs of business and IT services are more visible. Often, he added, a lot of infrastructure inside the enterprise “is discounted because there’s no clear or immediate benefit.”

Both SOA and cloud “have the same benefits because they both are essentially — fundamentally, architecturally, the same thing,” Dave continued.  “But that’s where SOA leaves it — as an architecture. Cloud is about external providers providing services and wrapping those things — including the contract, the SLA — and then delivering that to different constituents.”

I pointed out that the ramp-up to SOA provided some foundation for the cloud experience, since “one of the big issues that many companies had to come to terms with in SOA is the establishing service level agreements, because they necessarily didn’t know where the service was originating — from another part of the enterprise, or crossing the firewall.” reliability and scalability also needed to be guaranteed.

Ed noted, however, that whether its SOA or cloud, enterprise service consumers do typically have a handle on who is providing the service. “In a lot of the customer examples that we have — telco, healthcare, those kinds of things — they’re still interacting with a well-known group of users,” he pointed out. “It’s not random, you-don’t-know-who-you’re-interacting-with kind of situation.”

There are also lessons to be drawn from the SOA experience that can be applied to cloud computing as well, Ed said. For one, “start with a specific project that has some kind of reasonable boundaries to it, that’s going to have daily business impact when it’s done.  You want something that has regular use.” Also, Ed advised, “avoid the “boil-the-ocean architecture approach where we’re going to get everything to be cloud before we really do anything in cloud — we’ve seen that in SOA.” He recounted how one company developed a 72-page book of specifications,  looking at every possible policy consideration, before they even started working with an SOA methodology. “Those boil-the-ocean approaches probably fail more often than they succeed,” he said.

The best approach for SOA — and now for cloud — is more of a hybrid strategy that focuses on specific projects, but employs a broad-brush architectural approach. “One of the more successful strategies I’ve seen is kind of a hybrid of kind of broad strokes as to where the overall architecture is going, where we really want to end up in two, or three, or four, or five years even — but with some real practical realities around that initial project.” Also, another lesson from SOA: “Govern early and often. You don’t usually regret having done that early on — but you oftentimes regret not having done it if you don’t.”

I added this thought to the conversation: if one was to be attending a conference ten years from now, “you will see that cloud did change the way we look at SOA and for a couple of reasons.” First, through cloud computing, the business gained a better understanding of service orientation. “If you want to sell SOA to the  business, pitch it as cloud.”

Dave also raised the issue of cost structure, and how cloud — for better or worse — provides greater visibility into hidden costs that SOA does not address.

He illustrated the point this way:

“You and I are working in the same company.  You have a service, I’m using that, we shake hands. ‘Phil, throw an extra server in there because I’m going to add some capacity. How much capacity?  I don’t know yet. Okay, let’s go play golf.’  But now, I’m paying you to do the same thing as a cloud provider and I’m going to look at the bill. ‘Ooh, how come there are two servers on the bill?’  You might then go to your team say, ‘find another service somewhere and put it in.’”

The cloud providers will  provide their services at a specific cost, that’s the actual cost plus whatever the margin may be. Whereas, internal IT has always been kind of subsidized.  If you need a  project, you get internal IT to put it together for you, and delivered for you, and a lot of those costs  either were hidden, and were dispersed across the enterprise. Cloud is forcing organizations to look at the actual cost of service delivery and perhaps the alignment more with what the market will  be.

August 25th, 2009

Will vendors finally force SOA and BPM to mingle?

Posted by Joe McKendrick @ 9:43 am

Categories: SOA Surveys and Research, Standards Watch, business process management

Tags: BPM, SOA, Service-Oriented Architecture (SOA), Business Process Automation, Operational Planning, Enterprise Software, Web Services, Strategy, Middleware, Software

In the wake of Software AG’s acquisition of IDS-Scheer, Dana Gardner raised this question at a recent BriefingsDirect podcast: “Is the SOA landscape is being driven by folks trying to do it all?” As he put it: “I thought the whole notion of SOA was being able to include more players and more components to interact and interoperate. What’s going on?”

SOA-BPM merger is inevitable, but is not being rushed

There’s been a trend toward consolidations and acquisitions in which vendors are scooping up or adding capabilities in hopes of being able to offer end-to-end SOA suites. Of course, Dana is right, in that the whole idea of SOA is independence from these catch-all solutions, and being able to pick and choose, swap in and swap out interchangeable solutions as needed.

What caught the panel’s attention with the Software AG-IDS Scheer acquisition was the possibility that vendors may start forcing business process management solutions into that end-to-end SOA mix as well. However, in this case, it’s likely that Software AG may keep BPM focused on the BPM side of its product line.

For example, Jason Bloomberg, who joined the panel, pointed out that the acquisition itself actually had little to do with SOA. “With the IDS Scheer acquisition, if you read through what Software AG is saying about this, they’re not connecting it with their SOA story. This is part of their BPM story. This is a way for them to build their vertical BPM expertise. That’s the missing piece.”

It may take time for the SOA and BPM worlds to come together anyway. It’s like the separate Francophone and Anglophone cultures that exist in Canada; the Scotts, Welsh, English, and Irish in the UK; the Flemish and Francophones in Belgium; or the residents of North and South New Jersey. They’ll all agree to exist under one roof, but that’s about it — they still want their own ways of doing things.

But as Tony Baer put it, there’s a new emerging element that may force the BPMers and SOAphones to talk, at least a bit: “There has always been a huge cultural divide between the business folks, who felt that they own BPM, versus the IT folks, who own the architecture or the technology architecture, which would be SOA. What’s really interesting and what’s going to stir up the pot some more — and this is still on the horizon — is BPMN 2.0, which is supposed to support direct execution.”

Until then, we can conclude that it’s not likely we’ll be seeing a lot of BPM stuff being shoe-horned into SOA suites. But, it is inevitable that SOA will rely more on BPM; and BPM will rely more on SOA. It’s inevitable.

August 20th, 2009

Debate: Is SOA still too immature to secure?

Posted by Joe McKendrick @ 3:19 pm

Categories: Data managemetnt, General, Links, Management, SOA Surveys and Research, Standards Watch, cloud computing

Tags: SOA, Service-Oriented Architecture (SOA), Web Services, Middleware, Enterprise Software, Software, Joe McKendrick

Two recent posts by leading SOA thinkers have different takes on the state of SOA security. Is it a monstrosity that is almost impossible to secure end to end, or is it something that can be started relatively simply and grown with proper attention and management?

Will SOA outgrow its insecurity?

Forrester’s Randy Heffner says we have reached a point where SOA is secure enough for prime time. However, he cautions, while WS-Security has helped standard Web services using SOAP, some careful navigation is required for full-blown SOA. But it’s doable. “Advanced SOA security - involving federation among partners, nonrepudiation, and propagation of user identities across multiple layers of service implementations - is in its early days,” Randy points out. Still, the need for robust SOA security will be inevitable. “Many user organizations will find that advanced SOA security becomes mandatory - especially with increasing data privacy and other regulations.”

JP Morgenthal takes a dimmer view on SOA security, pointing out the world really hasn’t agreed on a consistent definition of SOA, and, therefore, there may be issues with attempting to provide security. As he points out: “If you can’t define it, you cannot secure it!”

JP adds that while there is plenty of research and literature on the topic of cybersecurity, there’s very little that connects SOA and cybersecurity. The problem is that SOA touches so many parts of the technology stack, and each has its own security solutions and protocols.

“If you’re tasked with focusing on cybersecurity for your SOA, you could focus on locking down access to your Web services, stopping SQL injection attacks, addressing DDoS attacks against the service, etc. Each of these areas requires considerable knowledge of the entire computing stack from telecom through the hardware through the operating system and into the application. Holy rotten fish Batman! That’s a tall order for even the most adept team, but it’s made even more difficult by the fact that there aren’t that many cybersecurity experts available that understands this entire domain.”

Still, Randy Heffner takes a stab at designing SOA security, starting with virtual private networks and two-way Secure Sockets Layer (SSL) at the simplest level. “Hackers cannot even connect to an SOA-based service unless they steal a certificate and key from a service consumer,” he says. Move up a step or two, and the next option is to leverage “existing SOA security features in Java or .NET application platforms and concentrating SOA security within an SOA specialty product such as an enterprise service bus, SOA and Web services management solution, SOA security server, or SOA appliance,” Randy says.

Ultimately, even when starting with a simple SOA security such as VPNs or SSL, SOA proponents need to recognize that the process will develop into something more intricate. The key is “to anticipate the need for and leave paths open to build additional, deeper security functionality as business requirements demand and SOA security maturity allows,” Randy says.  We’ll grow and learn as we go along, he believes:

“Typically not all applications need all of your security requirements; initial applications may be able to do with a lighter-weight pass on building your SOA security solution, while later applications require you to fill in your solution with additional features….  Each time you make a pass through, you will learn more about how to build the most effective SOA security solution with the pieces that you have.”

Still, JP says the current crop of tools and protocols are too immature for top-to-bottom SOA. Things will only get more complicated as SOA-enabled services become part of cloud offerings. “What I have experience in with regard to the WS-* security mechanisms, security tools and technologies for securing Web-based and non-Web-based applications, still do not begin to address the real hard issues regarding cybersecurity in an SOA; especially as we expand the notion of service.”

SOA raises issues that never arose in the days of siloed applications and point-to-point Web services. Both Randy and JP recognize that securing a complex network that touches many parts of the stack is going to take work. Where they disagree is whether current approaches are at least a place to get started. JP adds that SOA is too much of an amorphous, changing entity on which to base solid security decisions.

August 17th, 2009

Another view: SOA is like a mosquito, spreading viral data

Posted by Joe McKendrick @ 8:31 am

Categories: Business ROI, Data managemetnt, Enterprise Architecture, Links, Management, SOA Surveys and Research

Tags: SOA, Mosquito, Service-Oriented Architecture (SOA), Web Services, Middleware, Enterprise Software, Software, Joe McKendrick

Just as the Internet has shown itself to be a speed-of-light carrier of rumors, gossip, and misinformation, so can service oriented architecture within an organization.

I just came across new book titled “Viral Data in SOA: An Enterprise Pandemic,” written by Neal Fishman, program director for information forensics within IBM’s Information Management group, which highlights the risks that emerge as more and more applications are interconnected across and between enterprises.

On the cover of the book is a mosquito.  A mosquito’s claim to fame is that it can pick up viruses and bacteria from any type of organism, and deliver the payload to any other type of organism on the planet. A human and a deer and a bird may not have much in common, but they can all share the same diseases.

Is SOA, then, a mosquito that can deliver payloads of bad data (what Fishman calls “viral data”) all across the enterprise — pandemic style — before it can be stopped?

Fishman points out that misinformation and bad data have been haunting and hobbling organizations — not to mention entire societies — since the dawn of time. Nowadays, of course, information travels at the speed of light, and SOA — enabling interoperability between all types of applications — becomes the “host” carrier. As he puts it:

“Overall, viral data in SOA has the capacity to become an enterprise pandemic and disable a company. Service-oriented solutions that incorporate interoperability, reusability, layering of abstractions, and loose coupling serve as perfect hosts to propogate misinformation. That is the knife’s edge of SOA.”

As often discussed at this site, data is often a last considering in SOA planning, but SOA really won’t function properly if it’s delivering bad data.

What can organizations do to control the proliferation of viral data across SOA-enabled infrastructures? Fishman makes these recommendations for a multi-pronged approach to taking the “viruses” out of data before it infects the entire business.

• A reference model for moving data
• Methods by which to assess data
• Capture of data provenance
• Use of meta-driven coding techniques
• Use of abstract model
• Use of contextual views
• Continuous monitoring
• An appropriate data architecture
• Data governance

The last item on Fishman’s list, data governance, fits very neatly into SOA discussions, because SOA governance ensures that the enterprise is behind the effort. Likewise, data governance helps ensure that the correct version of data is being deployed within the architecture.

August 14th, 2009

Gartner: SOA out of 'trough of disillusionment,' cloud on hype peak

Posted by Joe McKendrick @ 7:38 am

Categories: General, SOA Surveys and Research, Web 2.0-Enterprise 2.0, cloud computing

Tags: Trough, Gartner Inc., SOA, Service-Oriented Architecture (SOA), Web 2.0, Web Services, Middleware, Enterprise Software, Software, Internet

Gartner recently released its latest “hype cycle” diagram for 2009, which shows service-oriented architecture to be well past the “trough of disillusionment” and climbing the vaunted “slope of enlightenment.”

Cloud computing, however, is now at the pinnacle of hype (no surprise there, right?), and ready to plunge into the trough. Interestingly, Web 2.0 now seems to be emerging from the disillusionment trough.

Being on the slope of enlightenment is typically the stage where vendors, analysts, and pundits are no longer gushing about how wonderful and world-shattering the technology/methodology is. Nor are they ranting on about what a flop the thing is. Instead, it’s the roll-up-your-sleeves stage, when companies and their technology professionals are getting down and making the stuff actually work.

Next stop: The “plateau of productivity!”

Source: Gartner (August 2009)