Category: business process management
November 18th, 2009
No SOAP for this Navy
This is the third of three installments of my discussion with Jim Jennis, chief technology officer for the US Coast Guard Operations Systems Center, and Steve Munson, SOA branch chief for the US Coast Guard, about the department’s growing roster of service-orientation initiatives. In the first post, Munson and Jennis described the business case for SOA within the Coast Guard. In the second post, they discussed how they built organizational support.
Coast Guard opts for ‘lightweight’ services; now tackling governance and security issues
The US Coast Guard prefers more lightweight services for its maritime and inventory tracking systems. “We are very REST oriented,” Munson explains. “We like the REST model very much. So where applicable, we have leveraged it in a significant way to develop our service oriented architecture. Internally, Munson points out, the prevailing standard is POX, or Plain Old XML for message exchange. “We do not subscribe to the extra wrappers and envelopes and overhead that’s required to serve out SOAP-based services.”
“What we have found within the Coast Guard is that the Web services model, particularly the traditional RPC-style Web services, are not suitable for implementation in the Coast Guard’s architecture,” he explains. “Our architecture is fundamentally message based. Where we do implement Web services interfaces, they’re all document-driven Web services for external users, where those kinds of interfaces are required.”
Munson and Jennis are also seeing some reusability in its SOA-aware services, particularly for lower-level services. However, Munson cautions, “we certainly don’t want to oversell that yet.”
That’s because the SOA team is still wrestling with the technical aspects of service governance. “The issue around SOA governance is still a challenge for us as it is with any organization,” he explains. “We have not implemented, for example, any formal service registry or automated service discovery. Were continuing to look at how we want to do that.”
The issue with registry and repository solutions on the market, he says, is that they are oriented toward the traditional SOAP-based Web services. “Most of them are still tailored to the Web services approach,” he says. “Many of them don’t have good answers for non-WS-* type of registration.”
Data security is another challenge for the Coast Guard’s SOA team, and this is holding back the ability to offer services to port partners and other outside parties. “One of the challenges in an enterprise service bus, and an SOA architecture in and of itself doesn’t solve this, are all the security challenges surrounding data services, particularly once you get outside of your organization,” Munson says. Internally, within the Coast Guard organization, the security around services is pretty straightforward. But starting with sharing with external partners at any level, security rapidly becomes a challenge for us. Like other folks, were still looking at how to crack that nut, and we still don’t have a silver bullet for that yet.”
The Coast Guard soon intends to make some services available to other federal agencies and its port partners. For example, the Coast Guard is participating in an inter-agency program called Watchkeeper, in which data is provided as part of a homeland security system. “We have probably a dozen or more services that are in testing that will be deployed as part of that system,” Munson says.
Additional services being piloted — and still in development — will feed data to and from WatchKeeper to other Coast Guard systems, such as MISLE, MAGNet, MASI and others, Munson adds. Additional services leveraging the Coast Guard’s ESB and SOA include systems for the National Oceanic and Atmospheric Administration surrounding Right Whale speed enforcement zones, as well as a system for monitoring and tracking Self-Locating Data Marker Buoys (SLDMB) for Search and Rescue.
The Coast Guard is making substantial progress with its SOA effort, and Jennis and Munson credit this to the close coordination between their teams and the Coast Guard management. “If you define what SOA means for your organization, and go forward with that, you’ll get SOA right,” Jennis advises. “In our case, we’re very much tied to the Coast Guard’s mission, and the doctrine of the Coast Guard. But if you go with a lot of the buzzwords, and you don’t have a clearly defined meaning for what your SOA will look like, you’ll get in great trouble in a hurry.”
November 17th, 2009
SOA promotes a sea change for the US Coast Guard
This is the second of three installments of my discussion with Jim Jennis, chief technology officer for the US Coast Guard Operations Systems Center, and Steve Munson, SOA branch chief for the US Coast Guard, about the department’s growing roster of service-orientation initiatives. In the first post, Munson and Jennis described the business case for SOA within the Coast Guard.
The Coast Guard dipped its toes cautiously into the SOA waters
The Coast Guard’s SOA initiatives had top-level support early on from the upper echelons of management. “We’d been challenged by our new commandant, Admiral [Thad] Allen, to become a department leader in SOA, and the department was taking a hard look at that time on where they wanted to go with their SOA roadmap,” Munson explains. “So it was just an opportune moment for us to dive into this, and see if there was any technologies that made sense, and that we could leverage. So we’ve taken a very deliberate, very measured approach to this, and started with a lot of small pilot projects, to validate, not only the technologies, but the architectural concepts that we’re trying to support with them.”
Even with strong organizational support, the Coast Guard’s SOA team approached the effort from the ground up, starting with smaller pilot projects. The approach was “build a little, test a little,” Jennis says. “We took a very measured and deliberate approach to SOA – no ‘big-bang’ projects. Everything was carefully architected and focused at the business architecture, the mission support of the Coast Guard first and foremost. And the technology implementations were validated and tested against that architecture in business-focused pilots. That is key to our success so far – being able to take things slow, validate the architecture, focus on the business, and make sure got it right before we started rolling this stuff out in production.”
Since the Coast Guard’s IT budget is small and highly fragmented across functional areas, the team did not have a big budget in which to engage its SOA effort, Jennis and Munson say. But the effort has delivered results well beyond the relatively lean expenditures made for the program. For example, the Coast Guard now can quickly pull up real-time data on ships that are entering US waters.
“We can also support maritime domain awareness by fusing data from multiple different data sources,” Munson adds. “We have, for example, requirements from homeland security for ship-arrival notifications 96 hours before a vessel enters a US port. That data can be fused with a long-range tracking system that identifies whether vessels are really going where they say they are going. Its tremendous value to promoting homeland security.”
The Coast Guard has also employed SOA to better track and manage its spare parts inventory – potentially saving the service tens of millions of dollars. “We developed what we call an ‘authoritative parts service’ that was able to identify and accurately catalog the value of the Coast Guard’s spare parts inventory,” Munson says. “We identified in that category more than $60 million worth of incorrect Coast Guard inventory evaluation. Measuring that against the federal cost of funds index – which is like interest on your money – it saved the Coast Guard $60 million, times the value of the federal cost of funds.”
Next post: By necessity, a RESTful approach — and unresolved issues.
November 6th, 2009
Bridging the gap between BPM and SOA: look to the repository
Business process management (BPM) and SOA don’t have to live in two different worlds. In a new Q&A tutorial, enterprise architect extraordinaire Todd Biske provides practical advice about pairing BPM modeling tools with service oriented architecture.
The key lies in the registry/repository of services created to support SOA: “One of the most important things to consider is the ability of the BPMN tooling to take advantage of service metadata that exists in a registry/repository,” Todd explains. “Whether modeling within the tool is being done by process analysts or by developers, the ties back to your service repository are important.”
Then consider the two roles that engage in this collaborative process:
Process analyst: These individuals may be working with a BPMN model, which will consist of flow objects, connecting objects, swimlanes, and artifacts. The two items that have relevance within SOA are the activities (part of the flow objects), and the swimlanes, which represent ownership boundaries of functional domains, Todd points out. “If you have this taxonomy in your service registry/repository, it would be great to have it accessible to you during your modeling efforts.” Service invocations should be shared across processes, and integrated into the registry/repository.
Developer: It is up to these folks to “take that model and turn it into something that can be managed by the runtime BPM engine,” Todd explains. Developers ensure that automated information-generating activities are correctly mapped to the message flow, via the connection between the service registry/repository and the BPM tool.
November 6th, 2009
Event processing means more than 'speeding up' existing systems
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
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...]
October 19th, 2009
HR specialist asks Oracle: where's the 'fusion'?
In an analysis of last week’s announcement at Oracle OpenWorld that Oracle would finally be releasing its Fusion Applications next year, HR technology specialist Bill Kutik wondered out loud where and when we’ll see Fusion HCM (Human Capital Management) emerge in an SOA-ready configuration.
Despite Larry Ellison’s public pronouncement at the end of the show that Oracle will soon pull the trigger and release the new offerings, including Fusion HCM, Bill is still skeptical as ever. As he put it in a recent editorial in Human Resource Executive:
“From the short demos CEO Larry Ellison showed on stage at Oracle Open World — and even after examining enlarged screen shots from them — Oracle Fusion HCM seems to be only on par with our best current software.”
Bill alludes to the original promise of SOA in this regard, in which analysts and vendors predicted that new capabilities could be assembled in a relatively easy fashion to meet changes in the business requirements — a la Lego blocks. It seems that’s been a difficult state to reach, he says — and wonders if Fusion Applications will meet this vision. He expressed skepticism at Ellison’s continued pronouncements that SOA will enable Fusion to “easily connect to existing apps, even SAP.”
Bill is disappointed that more isn’t being said about the capabilities of Fusion HCM when it does arrive, and is even more than annoyed that Oracle is keeping everyone in the dark about it. He also says there has yet to be a clear migration path discussed for PeopleSoft and Oracle E-Business Suite customers.
He wasn’t all sour on the announcement, however — he’s glad to see Larry Ellison talked up the emerging Talent Management application that will be part of Fusion.
Additional note: The latest version of PeopleSoft Enterprise (9.1) was launched September 30. Paco Aubrejuan, Oracle vice president and general manager of PeopleSoft, will be holding a Webcast on October 28, 11:00 a.m. Pacific to discuss the latest release. (Register here.)
October 14th, 2009
How event driven architecture changes the SOA service flow
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 12th, 2009
'Lean IT': another buzzphrase for something we've been trying to do all along?
Customer in a restaurant: Waiter, bring me a steak, and make it lean.
Waiter: Okay, sir. Which way?
As reported in my last post, Sandy Kemsley has done a great job of covering Forrester’s Business Technology Forum, which focused on Lean IT.
But which way is IT supposed to lean? Alas, it seems Forrester is helping to heap another buzzphrase on the world that seems to describe things that have already been in motion for years. (Some say this is the case with service oriented architecture as well, by the way.)
What, exactly, is ‘Lean IT’? Wikipedia’s definition of Lean IT is vague and convoluted:
“Lean IT is the extension of lean principles to the development and management of information technology (IT) products and services. Its central concern, applied in the context of IT, is the elimination of waste, where waste is work that adds no value to a product or service.”
Yeah, so? Again, haven’t organizations been battling waste in IT since day one?
I don’t know who coined the phrase “Lean IT,” but it takes a page from “Lean Manufacturing,” which tightened up that sector in the 1980s and 1990s to survive the onslaught from more efficient and quality-driven overseas competition. Noah B. Kindler, Vasantha Krishnakanthan, and Ranjit Tinaikar of McKinsey & Company discussed the concept back in May 2007, claiming that application development and maintenance (ADM) productivity can be boosted up to 40% by eliminating waste from routine processes. “Application development and maintenance is a prime candidate for lean methods not only because it involves a great many processes with the potential to be optimized but also because large differences in productivity among organizations suggest that some are far less efficient than others,” they said. As they put it:
“Each category of waste in manufacturing has a counterpart in ADM, which can be thought of as a kind of factory that develops new applications according to business requirements. Changes to an application’s requirements are one common source of ADM waste, causing many of the classic varieties identified in lean: designers rework their specifications, coders wait for specifications to stabilize, testers overproduce as their testing environments have to be set up repeatedly, unmet requirements pile up in a large backlog. As in manufacturing, systematically eliminating these sources of waste improves the delivery time, quality, and efficiency of the ADM end product.”
So they equate IT operations with a manufacturing process. Which makes sense, and is something we’ve discussed in this blogsite before (here, here, and here). By introducing assembly-line processes and greater automation to software development, we can definitely tighten up the process.
In past posts, I quoted IBM’s Dr. Irving Wladawsky-Berger and Microsoft’s Jack Greenfield, both who said we were at the dawn of a new era of IT — “industrialization.” Wladawsky-Berger said that IT-delivered services are starting to become more componentized, standardized, and mass-consumable across the spectrum, just as manufactured goods were a century ago. Greenfield talked about the concept of the “software factory,” defined as “a development environment configured to support the rapid development of a specific type of application. While software factories are really just the logical next step in the continuing evolution of software development methods and practices… introducing patterns of industrialization.”
He said, however, that “our IT infrastructures are nowhere near ready to handle this explosive growth of information and service. Much of IT, - including applications, data centers, systems management, and so on, - is way too ad-hoc and custom designed, sort of like manufacturing was decades ago….”
So, is Lean IT the right thing at the right time to seize upon this impending industrial revolution of IT services? The McKinsey authors identify the following areas for “waste reduction” in software assembly: flow processing to reduce overcapacity or excess inventory; release schedules to help prioritize projects; staff and supplier workload balancing; greater standardization; segmentation of projects by complexity to route projects to the proper resources; and and by avoiding unnecessary overhead for simple tasks; and quality ownership that extends to all groups involved in software production — not just QA.
These are are well and good goals, and I’m sure every organization can benefit greatly by applying these principles to their IT operations. But is there anyone who hasn’t been already trying to move these efforts forward? What does Lean IT bring to the table? Consider everything that has been underway in recent years:
- Service oriented architecture: Formerly siloed applications are decomposed into reusable services that are made available across enterprises.
- Agile development: Developers work side by side in an iterative way with business users throughout the process.
- Virtualization: Physical IT systems and resources are abstracted into a software-based enterprise service layer.
- IT automation: Routine IT processes formerly handled manually are handled on a systematic basis by the software and machines themselves.
- Cloud computing/outsourcing: Non-critical IT tasks and applications are acquired from more specialized providers, mainly on a pay-per-use or contractual basis.
- Business process management: Business workloads are decomposed and automated.
- ITIL: Best practices and principles for IT services applied uniformly across organizations.
References I’ve been seeing to Lean IT seem quite provincial — optimizing IT processes at the ground level without bringing in the larger picture — the transformation of the business. Lean IT lacks the expansive thinking that Wladawsky-Berger and Greenfield have in mind for the coming industrial revolution in IT services.
And, again, it begs the question: what does Lean IT offer that we haven’t been trying to do already?
October 9th, 2009
Question: can packaged apps join the 'Lean IT' bandwagon?
Answer: It depends if you wear a ponytail.
Sandy Kemsley has been providing wall-to-wall coverage of the Forrester Business Technology Forum in Chicago, and picked up on an interesting panel discussion on the role of packaged applications in Lean IT. (Lean IT is the theme of Forrester’s confab.)
Sandy’s reports on Forrester BTF are a good read for anyone trying to get their heads around the concept of “Lean IT.” (She starts here with her series.) I mean, isn’t that what we’ve been trying to do for the past 20 years anyway? (Not that things have turned out that “Lean” yet. We’ll see if it works this time around.)
According to Sandy’s report, Forrester’s John Rymer argued that “packaged apps can never be Lean, since most are locked down, closed engines where the vendor controls the architecture, they’re expensive and difficult to upgrade, they use more functions than customers use, they provide a single general UI for all user personas, and each upgrade includes more crap that you don’t need.”
Chip Gliedman, a Forrester analyst, argued the opposite side, stating that the opposite of packaged apps — custom-grown apps — are just about as bloated and klunky as you can get. You need packaged apps to pave the way to Lean IT. Sandy quotes Chip as “pointing out that you just can’t build the level of functionality that a packaged application provides, and there can be data and integration issues once you abandon the wisdom of a single monolithic system that holds all your data and rules.”
I like Sandy’s summary of the whole thing: “Clearly, Gliedman is either insane or a secret plant from [insert large enterprise vendor name here], and Rymer is an incurable coder who probably has a ponytail tucked into his shirt collar. :) Nonetheless, an entertaining discussion.”
September 30th, 2009
Seven ways companies go wrong with SOA
Remember, SOA is a journey, not a quick overnight fix. It’s a transformative process that your organization will follow for the long run.
A few years back, I put together a list of where companies appeared to be steering in the wrong direction in terms of SOA implementations. The list bears repeating, because the issues still keep getting in the way of SOA success. Many companies run the risk of jumping into the approach without looking at where they are leaping. Here are the most common pitfalls that could tie an SOA installation into knots.
1) Viewing SOA as a global, enterprise-scale project involving the entire enterprise: An SOA need not be a galactic initiative that sucks up resources all across the enterprise. In fact, one of the beauties of SOA that it can start small and simple, deployed across a single business process. Definitions of SOA vary, but SOA can start with something as simple as some Web services that accomplish an end-to-end process, such as fulfilling a purchase order.
2) Looking to a single vendor to offer very complete SOA solutions: There’s no such thing as buying an SOA solution; there’s no such thing as SOA in a box, no matter what a vendor may tell you. SOA is not a product that a vendor can ship to you for installation over the weekend. Rather, SOA is a philosophy around developing your infrastructure using those vendor tools. If you have a J2EE or .NET Framework, you have a framework. An SOA is what you eventually do with those frameworks.
3) Assuming that SOA will automatically grow out of a primordial soup of Web services: Many companies think they have SOA when they actually have a JBOWS (Just a Bunch of Web Services) architecture. Somehow, there’s an assumption out there that a spaghetti architecture of Web services will somehow evolve into something resembling a full-functioning SOA. Actually, it’s possible (but not advisable) to build an SOA-enabled infrastructure with no Web services at all. An organization could have 1,000 Web services, but unless these services work in concert to address specific end-to-end business processes, that does not an SOA make. One additional point about JBOWS, however — there’s nothing wrong with being in the JBOWS stage of evolution, because that’s what it is, a stage of the evolution. But don’t expect the full-fledged agility of SOA at this stage — that’s where the disappointment has crept in.
4) Build it, and they will come: SOA is not an illuminated ballpark in the middle of a cornfield that can be seen from miles around. No one will take advantage of an SOA-enabled infrastructure if they don’t know where to find it, or even if it exists. There’s a rule that if developers have to spend more than 10 minutes to find what they are looking for (and don’t find it), they will create it themselves. An SOA will never be of value if it’s confined to one silo of the organization, and its components are not made available and shared across business unit. An SOA service built, managed, and used by one business unit will cost just as much as any other legacy application.
5) Assuming that businesspeople don’t, or won’t, understand SOA: Actually, most people on the business side can intuitively grasp the potential savings and opportunities an SOA can bring. And Enterprise 2.0 and the cloud dynamic really drives the points about service orientation home on the business side. The potential of reusing services across various business units, versus paying developers to rebuild a new service in each instance, is Management and Finance 101. The difficult part is building and managing such an infrastructure, applying IT governance, monitoring, and management to ensure that services are kept up and running, are scalable, and perform well.
6) Assuming that IT people don’t, or won’t understand the business: It’s time to put this misconception, which has been weaving its way through conferences, articles, and analyst reports for years, to rest. Indeed, SOA needs to be a multi-disciplinary, cooperative effort between IT and other departments. However, IT is part of the business, and IT professionals’ paychecks are signed by the business. Most IT departments understand that they play a vital role in moving the business forward. However, inevitably, specs and priorities will change during the life of a project, and that’s why projects fail. It’s incumbent on both IT and business users to keep each other informed; both have a financial stake in the business’s success.
7) Treating SOA as something far superior to a mere mortal “project:” SOA success is delivered one project at a time. If you have been to any number of SOA conferences, or tuned into the multitude of SOA Webcasts, you probably have heard the message over and over again that “SOA is more than just another project.” Yes, true. SOA does represent a new way of thinking, and will transform your IT, and ultimately, your business processes. However, SOA still needs to be treated as a project, with the same deliberate planning of timelines, establishment of baselines, and measurement of key performance indicators as other large IT projects. SOA requires executive buy-in, it requires resources, and it requires proof that it is paying off.
September 29th, 2009
SOA, event driven architecture will be in smart systems everywhere
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 23rd, 2009
Cisco practices what it preaches, crosses boundaries with SOA
Cisco Systems apparently is doing a great job of practicing what it preaches when it comes to doing business over the network. The network systems provider — which promotes SOA and SONA (service oriented network architecture) — recently launched a “Commerce Transformation” initiative, based on SOA principles, that enabled the company to create a solid architectural and technology foundation for both existing and future application development. And the company is getting measurable results.
Cisco more than tripled transactions to $4 billion in a year via its SOA-based partner application
The initiative netted Cisco top honors as the most compelling case study for 2009, as determined in a competition held by the SOA Consortium and CIO Magazine. Brenda Michelson, a colleague over at ebizQ and a judge for the case study competition, provides a detailed description of the Cisco Systems SOA program.
The first project, the Partner Deal Registration (PDR) application, provided outside partners secure access to “Cisco pricing concessions and programs, leveraging reusable enterprise-class business services such as corporate pricing, configuration, and partner profiles that were coupled with flexible business rules for price lists, contractual discounts, and promotions, among others.”
Part of the challenge was bringing together more than 400 diverse applications based on various acquisitions, Brenda relates. “Consequently, several core business processes such as product ordering and pricing were becoming inconsistent, monolithic, complex, and inflexible to change. A lack of comprehensive end-to-end monitoring was also a concern.”
Benefits seen as a result of the program included improved process agility, productivity, detail tracking, and growth in the number of partners, deals, and bookings. “Six months after initial project rollout, the system had more than 9,000 partner users worldwide and had processed 37,000 deals worth $1.2 billion. Nearly a year later in June 2009, there were close to 20,000 partner users, and 56,000 deals worth $3.92 billion net had been processed.”
Cisco had a very comprehensive governance structure for its SOA, led by cross-functional councils comprising business and IT leaders were tasked with the planning and execution of an integrated capabilities roadmap, Brenda relates. Once the roadmap was finalized, an SOA project team consisting of an enterprise architecture team, business architects and IT architects evaluated the use of SOA. The EA team, which also acted as an SOA center of excellence, built a framework for the identification, creation, reuse, governance and monitoring of services and composite applications.
Brenda outlined some of the lessons learned. Some are well-accepted operating procedures across the industry, such as SOA governance, being about the business versus technology, and employing both a top-down and bottom-up approach becoming essential. Interestingly, one of the lessons is that business process management (BPM) needs to be part of the SOA equation. Also, the Cisco folks point out, “when you are a large company, most of the benefits will come from volume, so target simple things (services) with high volume.”
September 22nd, 2009
Services or subtasks? SOA and BPM may mean the same thing
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 8th, 2009
Advice: avoid SOA-BPM entanglements
Does it make sense to fuse SOA to business process management (BPM)? Many see the SOA-BPM alliance as an inevitable convergence — a topic we’ve riffed on repeatedly here at this blogsite.
Should SOA be viewed as ‘the nail for BPM’s hammer’?
So, the SOA-BPM alliance is a great thing, right? Actually, at least one informed observer questions whether SOA and BPM were really meant to be together at all. JP Morgenthal cautions that “SOA and BPM have very different goals. SOA is about application rationalization via a service metaphor, and BPM is about business process analysis and optimization.” They are not — repeat, are not — related, JP says.
A SOA-BPM union, forced or otherwise, may even create some big problems, he adds:
“This entanglement of SOA and BPM into a single effort is fraught with problems and failure. Each initiative should be undertaken separately and with definitive goals that do not list each other as one of the outcomes. If as part of the rationalization that SOA provides, there happens to be some services exposed that simplify the implementation of a particular business process, then that would certainly be a slam-dunk. However, SOA and BPM each have their own metrics of success and their own barriers to success. Combining them into one, well, the words ‘boiling the ocean’ comes to mind.”
Plus, attempting to fuse SOA and BPM into one mega-effort is biting off more than most organizations can chew, he warns. SOA practitioners may see the mapping business processes into technology frameworks as the be-all and end-all. However, the BPMers are usually focused on other things, such as getting business units that may reside in separate continents on board with a redesign process. This is a bigger deal “than not having a Web service available to invoke,” he says. As JP puts it, “SOA should not be viewed as the nail for BPM’s hammer.”
JP’s view runs contrary to what many other analysts/observers seem to have been saying in recent years, that while clearly still distinct and separate, SOA and BPM are coming together, and the lines between the two disciplines are blurring. JP argues that SOA and BPM should not be one single effort, which, from a digestible project management perspective, makes sense. And BPM can currently exist without SOA. However, there is a lot of work taking place on the SOA side in terms of architecture, which lays out the blueprint for the most effective deployment of technology to support business processes. Business leaders don’t care if an initiative is called “SOA,” “BPM,” or “EA,” or “DOA.” They want an initiative that achieves faster time to market, streamlines an outmoded process, or improves front office productivity.
September 2nd, 2009
Enterprise architecture is for entrepreneurs, too
Mike Kavis asks an intriguing question: “Is enterprise architecture only for big companies?”
Small companies can’t afford to throw money away on the wrong systems
One’s first thought would be yes — it would seem that a larger organization would have a greater need for EA, since there are likely to be many systems, applications, and user groups to contend with, all under one roof. A small company, on the other hand, may be more homogeneous, with only one ERP system, one type of database, one platform, and so on. Plus, a large organization has lots of time and resources — including human resources — that can be devoted to EA planning and governance activities.
EA may be even more critical to small and medium-size companies than their larger counterparts. But there is a misconception that only big companies need EA. Mike reports that he is part of a startup with fewer than 20 employees, and yes, they are talking EA. He says Brenda Michelsen captured the misconceptions about EA perfectly in a within-140-character tweet: “Many equate EA w/jumbo frameworks & rigid governance, rather than set of values & practices for capability delivery.”
So, forget the heavy-handed frameworks, and look at what EA is really about:
“Enterprise Architecture is a complete expression of the enterprise; a master plan which ‘acts as a collaboration force’ between aspects of business planning such as goals, visions, strategies and governance principles; aspects of business operations such as business terms, organization structures, processes and data; aspects of automation such as information systems and databases; and the enabling technological infrastructure of the business such as computers, operating systems and networks (source: IFEAD – Institute for Enterprise Architecture Developments)”
There’s nothing in this definition that specifies large organizations. If anything, smaller companies may need a master plan to guide ongoing technology projects more than a large organization that can afford to waste money on shelfware or underutilized systems.
Mike observes that EA is effective at helping a small, entrepreneurial organization meet goals that may include business architecture, business roadmaps, and portfolio management that prioritizes what gets worked on and when.
August 31st, 2009
Wal-Mart to compete against Amazon; are Wal-Mart Web Services next?
Wal-Mart, the gigantic discount retail which is able to offer discounts via a well-orchestrated systems-based supply chain, announced it is launching an online marketplace featuring close to a million items from various sources.
Speculation is that this is Wal-Mart’s move to capture some of the success Amazon has seen in the online space. While the retail sector suffered through the recent economic downturn, Amazon blazed along with barely a hiccup.
Now, if Wal-Mart really wants to take on Amazon across the board, they should consider an entree into the cloud space, such as that dominated by Amazon Web Services. Amazon essentially took its vast array of IT assets built for its e-commerce operation and turned it into a shared offering for the business IT sector.
Will we eventually see Wal-Mart do the same with its massively expanding IT infrastructure? Wal-Mart Web Services, anyone? (This is a tongue-in-cheek speculation, sort of…)
August 27th, 2009
Cloud: the SOA we always wanted, but never had?
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 26th, 2009
SOA security: isn't SOA itself a security solution?
Mark O’Neill picked up on my recent post on SOA security and asks a very logical question: Why aren’t we looking at SOA as an enabler of security, versus worrying about the security of SOA approaches?
We’re asking the wrong question about SOA security
A very good question indeed. Mark calls this the “neglected flipside of SOA security,” observing that “SOA Security” is two separate things, solving two separate problems — securing SOA-based infrastructures, and applying SOA principles to security. “I think that too many SOA Security articles focus only on the first meaning of SOA Security (making SOA more secure) than on the second (applying SOA principles to security to make it more easy to deploy and manage),” Mark says.
He explains:
“‘SOA-flavored Security’ means making security more management and easy to deploy by isolating re-usable components of security and providing them as managed services. For example, the OASIS DSS standard explains how digital signature services can be used in order to provide signing and signature validation services over the network, accessed using a Web Services interface. This solves a knotty problem, and provides a good framework for key management. Similarly, specifications such as XKMS, XACML, and WS-Trust are really all about applying SOA to security, to solve interoperability problems, not about ‘making SOA secure.’”
A few weeks back, I quoted Open Group’s Dr. Chris Harding, who also pondered whether we’ve been looking at the SOA security problem “the wrong way around.” Chris suggests SOA and the use of shared services may actually solve more security problems than it creates.
The beauty of a service-oriented approach is that it provides for common mechanisms — security services — that can be developed and tested and applied against many types of applications or scenarios. Individual domain or application owners no longer need to reinvent the wheel, rely on jury-rigged approaches, or cross their fingers if common SOA-based security is available within the enterprise to secure their application and data assets.
Again, SOA may solve more security issues than it creates.
August 25th, 2009
Study: unified communications doesn't deliver -- yet
It would seem that converting technology that has existed as proprietary, embedded-code hardware-driven solutions to service-oriented software would be very productive.
Needed: baselines to measure UC gains
However, unified communications (UC) approaches still have yet to prove their ROI mettle, a new Forrester Research study claims. As reported by Tim Greene in Network World, half the world is not convinced of the efficacy of UC. Forrester’s Henry Dewing is quoted as observing that half the companies he spoke with don’t yet see the business value in UC. “When you talk to end users, they want a 12-month return and a triple-digit ROI,” he says.
For many businesses, the challenge is determining a baseline of costs before UC is implemented, Dewing says. UC brings various communications methods — including IP telephony, instant messaging, email, and voice mail — into more integrated settings running on standard IT systems. Benefits include measurable, quantifiable metrics such as cutting down on business travel (in favor of teleconferencing) and enabling the decentralization of call centers.
However, there are many soft benefits such as cutting down wait times and increased end user productivity. Good stuff, but notoriously difficult to measure. Perhaps we will start seeing more cloud-based UC services that will add incremental pricing into the equation.
August 25th, 2009
Will vendors finally force SOA and BPM to mingle?
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.
Joe McKendrick is an author and consultant with deep knowledge and insights regarding trends and developments in the technology industry. See his full profile and disclosure of his industry affiliations.
Subscribe to Service Oriented via Email alerts or RSS.
SponsoredWhite Papers, Webcasts, and Downloads
- Virtualization: Architectural Considerations And Other Evaluation Criteria VMware Of the many approaches to x86 systems virtualization available in the ... Download Now
- The Impact of Virtualization Software on Operating Environments VMware Today's use of virtualization technology allows IT professionals to ... Download Now
- Three Steps You Need to Know to Stop Data Loss Varonis Sensitive data exposed to misuse or loss... it is the stuff of nightmares ... Download Now
Essential Topics 
- Top-ranked Novell support for Red Hat at 50% less
- Get top-ranked Novell support for Red Hat when you switch
- Move to SUSE Linux Enterprise. Get 3 years of Red Hat support
- More interoperability, plus 3 years. Red Hat support, only from Novell
- Red Hat support, patches, updates with the interoperability of Novell
- Unrivaled Red Hat support now available from Novell
Recent Entries
- Hello, I’m a Cloud… and I’m Enterprise Software
- SOA Manifesto: Manes explains manifesto’s aims
- Cyber Monday approaches — should companies clamp down on employee online shopping?
- Popping the buzzword bubble
- Panel: do cloud computing economic advantages break down in enterprises?
Blogs From Our Sponsors
Most Popular Posts
- Why IT can't seem to deliver measurable productivity
- IT project risk aversion 101
- US defense department IT managers describe latest assault on complex and siloed IT systems
- No SOAP for this Navy
- SOA promotes a sea change for the US Coast Guard
- Panel: do cloud computing economic advantages break down in enterprises?
Top Rated
- No SOAP for this Navy+4 votes
- Popping the buzzword bubble+4 votes
- ARIN CEO reminds: be prepared for Internet numbering expansion+3 votes
- Hello, I'm a Cloud... and I'm Enterprise Software+3 votes
- SOA Manifesto: Manes explains manifesto's aims+3 votes
- Gartner: 10 reasons why both sides of the SOA debate have it wrong+3 votes
- IT project risk aversion 101+3 votes
- Enterprise mashup, defined+2 votes
Premier Vendor Content Whitepapers, webcasts & resources from our Power Center Sponsors
- New Online Dashboard for IT Leaders
-
Read about top issues IT decision-makers face every day, plus get cost-effective solutions to real-life IT problems.
- Learn more >>
- Save time with automated shipping solutions
-
The Business Essentials Guide provides you useful tools and templates to help grow your business and save you time with automated shipping solutions.
- Visit the UPS Business Essentials Guide
- Microsoft Dynamics CRM Online - Free Six-Month Trial for Eligible Organizations
-
Microsoft Dynamics CRM Online provides fast online access, simple contact management and better sales performance for a low monthly cost - the best value on the market today.
- Learn more about the free, six-month trial offer>>
Archives
Favorite Links
IT & business transformation
SOA Blogs
ZDNet Blogs
- All About Microsoft
- The Apple Core
- Between the Lines
- BriefingsDirect
- Collaboration 2.0
- Dev Connection
- Digital Cameras & Camcorders
- Ed Bott's Microsoft Report
- Emerging Tech
- Enterprise Web 2.0
- Forrester Research
- Googling Google
- GreenTech Pastures
- Hardware 2.0
- Home Theater
- iGeneration
- Irregular Enterprise
- IT Project Failures
- Laptops & Desktops
- Lawgarithms
- Linux and Open Source
- Managing L'unix
- The Mobile Gadgeteer
- On Sustainability
- Rational Rants
- The Semantic Web
- Service Oriented
- Smartphones and Cell Phones
- Social Business
- Social CRM: The Conversation
- Software & Services Safari
- Software as Services
- Storage Bits
- Team Think
- Tech Broiler
- Technology and the Global Supply Chain
- Tom Foremski: IMHO
- The ToyBox
- Virtually Speaking
- The Web Life
- ZDNet Education
- ZDNet Government
- ZDNet Healthcare
- Zero Day
White Papers, Webcasts, and Downloads
- Why Isn't Server Virtualization Saving Us More? A Few Small Changes May Dramatically Increase Your Efficiency VMware Companies have rapidly adopted server virtualization over the past few ... Download Now
- Building the Virtualized Enterprise with VMware Iinfrastructure VMware VMware virtualization software has been adopted by over 120,000 enterprise ... Download Now
- The Impact of Virtualization Software on Operating Environments VMware Today's use of virtualization technology allows IT professionals to ... Download Now
SmartPlanet
- Thought-provoking progressive ideas on diverse topics that intersect with technology, business, and life, and matter to the world at large. Visit SmartPlanet
- More from IBM
-
- Innovate your business' process model, play against the market, compete against others on our scoreboards and WIN! Try INNOV8 2.0: A BPM Simulator
- Enabling Real-World Business Transformation through IBM Service Management Read the EMA Analyst Report
