Category: Enterprise Architecture
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 16th, 2009
SOA helps Coast Guard navigate new tides of homeland security
Did you know the movement of any ship headed toward US waters is tracked by an SOA-aware service running on the US Coast Guard’s systems? And that SOA services are being employed to provide data to an international registry of maritime activity? And there is also an SOA service keeping track of the all the spare parts, equipment, and other assets the Coast Guard maintains? 
The Coast Guard already has close to 25 services that are either already or about to go into production as part of its growing SOA initiative – and more are planned. I recently had the opportunity to speak 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.
The Coast Guard – part of the US Department of Homeland Security – started looking at SOA in early 2007, as a way to address growing requirements to be able to share information not only across its own various units, but with federal, local and international agencies concerned with keeping an eye on vessels entering and leaving US shores. “We had the same conundrum of silos of excellence that many IT organizations have – IT systems tailored in stovepipes within lines of business,” says Munson.
Prior to its SOA implementation, the Coast Guard relied on slower and more manual methods of data sharing with its port partners. “It would either be some form of composed file that would be potentially handed over, or many times, a hard-copy printout or phone call,” Munson relates. In addition, sharing data with its fast-moving cutter fleet was also a challenge. “The cutters get underway and go where they’re needed, so we have fairly low-bandwidth connectivity to these kinds of assets at best,” Munson says. “So were also looking at not only data sharing, but also if there’s a better way with emerging technology to help address some of the problems of being able to use our systems with deployed assets.”
To address these requirements, the Coast Guard implemented an enterprise service bus-centered SOA that enabled asynchronous messaging from Fiorano Software Technologies. The solution was employed in the Coast Guard’s Long Range Identification and Tracking (LRIT) system, which at any given time, is tracking up to 6,000 vessels moving toward or in US waters as well as vessels anywhere else in the world. LRIT tracks signals emitted from vessels every six hours. “That information is running entirely on the Coast Guard’s SOA framework in production,” says Munson. As a result, the Coast Guard SOA requires extremely high-volume services, “processing thousands of messages per second.”
A second system, the Nationwide Automated Identification System (NAIS), relies on a second transponder on ships exceeding 300,000 gross tons, broadcasting navigational information for ships of 300 gross tons or more at three-second intervals. These broadcasts from US territorial waters result in about 2,000 messages per second received in the NAIS system. The Coast Guard is currently protoyping various data services around this system for maritime domain awareness, Munson says.
This is the first of a three-part series. Next post: How the Coast Guard built organizational support for SOA.
November 13th, 2009
Data services may help address a major SOA unknown -- data quality
A couple of months ago, as reported here, Neal Fishman released a book that warned of SOA-based infrastructures helping to spread “epidemics” of viral data across enterprises — since data can be pulled from multiple, formerly siloed sources and quickly distributed across service-oriented systems and applications.
How much data pulled from multiple sources is bad data?
Informatica’s Ash Parikh, a long-time advocate of the data services approach to SOA, has also been warning of this scenario. I have gotten to know Ash through our participation on the Informatica Perspectives site, and recently had a chance to talk to him and Informatica’s Chris Boorman prior to the launch of Informatica 9, which embraces the SOA data services concept.
Ash proposes that organizations adopt a data services layer that provides “a model and standards-based reusable data abstraction layer that can make holistic, accurate and timely information available to an enterprise integration infrastructure, without all the typical complexity and maintenance costs.” He defines a data service as “a modular, reusable, business-relevant service that enables the access, integration, and delivery of complex enterprise data throughout the enterprise and across corporate firewalls in batch, near real-time and real-time modes, including federation.”
As companies move into the next level of SOA maturity, in which services start reaching across enterprise boundaries, many have been struggling to improve SOA’s ability to deliver business value. One factor is companies can’t trust the data that is being pulled in from all the stovepipes into enterprise services. SOA, as Chris puts it, “has lacked the data abstraction layer that enables organizations to basically define the data objects and the rules associated with data objects, that can then be permeated through — whether it be Web services or SQL or batch or anything else — to the applications that are using that data.”
Ash, who has been warning the industry about the quality of data — or lack thereof — surging through SOA-based infrastructures for some time now, says SOA data services open up many new avenues for connecting SOA with enterprise data management. “It’s much more than just data access,” he points out. “It’s making sure the data that is delivered is of the greatest quality.”
SOA data services also helps create a more collaborative environment between IT, data managers, and business data owners. In the real world, Ash says, “when people talk about data, they never talk about ‘data source X’ or ‘data source Y’ that’s sitting in a corner somewhere,” he says. “They report the data as a business representation of data — my customer data, my product data, things like that” This brings things in line with the perspective required of SOA architects, who need to better assure more timely and accurate and consistent views of their data and the product data.
Given this backdrop, I saw that Mike Kavis also has been doing work in this area, and just posted a business case for data services at his site. He describes the issues that can be rectified via an abstracted data layer: real time failover among multiple virtual data centers; managing multi-channel partners with multiple data structures; regulations and laws affecting data management and movement; and data security against direct access to databases.
Maintaining a loosely coupled data services layer takes away the complexities and inconsistencies of attempting to manage multiple data sources. “By abstracting the data layer and creating configurable services as access points to the data, teams can quickly implement solutions in a controlled and standardized manner,” Mike says. For example, they can move quickly “due to the simplicity of the data access and the fact that they don’t need extensive knowledge of the underlying data.”
Ash Parikh also talks about the divide between data management and real-life business needs, something that SOA and data services can help address. For example, he observes, many companies have built great data models, but these models tend to be static. “It’s great to have a model, but I also need a way to find all that information, and to make sure that information I’m finding across a multitude of these data sources – which can be varied in structures and formats — is relevant to me.” Many of these issues can be resolved at the data services abstraction layer, he says.
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 26th, 2009
SOA, Roman, Greek, or Modern: you don't 'do' architecture
Service oriented architecture is not a thing that you do, and it definitely isn’t a thing that you buy. But it is something tangible, a style if you will, just as Roman, Greek or Modern are styles of architecture.
Why the fussing about semantics? This was a key point discussed over and over again by members of the SOA Manifesto Working Group, and an issue that is endlessly creating confusion in the market. In fact, it’s a semantic slip that even members of the group had to work at to keep in check.
There have been some comments raised about the Manifesto’s preamble, which said the following:
“Service orientation is a paradigm that frames what you do. Service-oriented architecture (SOA) is a type of architecture that results from applying service orientation.”
Yes this opening statement may seem like a statement of the blindingly obvious, like “the sky is blue” or “the ocean is wet” or “Hollywood makes crappy movies” or something like that. But there was a lot of discussion around this statement, and the intent was to dispel the notion that SOA is this thing that you do or can buy. In fact, vendors and consultants have been abusing these semantics and milking millions from customers with this notion for years.
That makes as much sense as the Romans going out and buying their architecture. It was important to put this notion to rest (definitely no pun intended) once and for all, and it was felt by the group that this was such an important statement that it was elevated from originally being a principle to the preamble to the entire document. And “applying service orientation” is the action that goes into building an SOA-enabled infrastructure.
October 23rd, 2009
SOA Manifesto unveiled
As mentioned earlier, I had the opportunity to join a group of highly motivated and very smart people at the SOA Symposium in Rotterdam to formulate what is being called the SOA Manifesto. Here is the final version of the document, spelling out the core values and related principles that should be part of service orientation and SOA. Hopefully, they will help guide your thinking on the SOA journey:
SOA Manifesto
Service orientation is a paradigm that frames what you do. Service-oriented architecture (SOA) is a type of architecture that results from applying service orientation.
We have been applying service orientation to help organizations consistently deliver sustainable business value, with increased agility and cost effectiveness, in line with changing business needs.
Through our work we have come to prioritize:
- Business value over technical strategy
- Strategic goals over project-specific benefits
- Intrinsic interoperability over custom integration
- Shared services over specific-purpose implementations
- Flexibility over optimization
- Evolutionary refinement over pursuit of initial perfection
That is, while we value the items on the right, we value the items on the left more.
SOA Manifesto Guiding Principles
We follow these principles:
- Respect the social and power structure of the organization.
- Recognize that SOA ultimately demands change on many levels.
- The scope of SOA adoption can vary. Keep efforts manageable and within meaningful boundaries.
- Products and standards alone will neither give you SOA nor apply the service orientation paradigm for you.
- SOA can be realized through a variety of technologies and standards.
- Establish a uniform set of enterprise standards and policies based on industry, de facto, and community standards.
- Pursue uniformity on the outside while allowing diversity on the inside.
- Identify services through collaboration with business and technology stakeholders.
- Maximize service usage by considering the current and future scope of utilization.
- Verify that services satisfy business requirements and goals.
- Evolve services and their organization in response to real use.
- Separate the different aspects of a system that change at different rates.
- Reduce implicit dependencies and publish all external dependencies to increase robustness and reduce the impact of change.
- At every level of abstraction, organize each service around a cohesive and manageable unit of functionality.
October 23rd, 2009
Anne Thomas Manes: SOA can be resurrected, here's how
SOA may have its detractors, but done right, it lays the groundwork for a new service-oriented paradigm going forward.
I’m at this year’s International SOA Symposium in Rotterdam, and the prevailing theme is “Next-Gen” SOA, in which we see service-orientation emerge from its bout with the skeptics to take a stronger role within the enterprise.
Thomas Erl, the conference organizer and prolific author on SOA topics, launched the event, noting that we are moving into a period of Next-Generation SOA, with the foundation of principles and practices being laid within many entreprises.
Next up was Anne Thomas Manes of Burton Group, who declared in a post at the beginning of the year that “SOA” — at least as we knew it — was “dead.” However, the second part of Anne’s post was “Long Live Services,” which is the theme that she picked up on in her keynote address.
“Business wasn’t really interested in buying something called ‘SOA,” she declared, adding that in her own research, fewer than 10% of companies have seen significant business value in their efforts.
However, that is not to diminish the importance of service oriented architecture. “The average IT organization is in a mess,” she says. “The average business has 20 to 30 core capabilities. Why do they need 2,000 applications to support those 20-30 capabilities?”
“We should be service orienting everything we do,” she contends. What’s getting in the way is the feeling that an “SOA program” needs to be launched to get there, she states. “We have an opportunity at this point to resurrect SOA. We need a different approach, one based on architectural principles.”
Anne also observed that current cloud computing initiatives bear a striking resemblance to SOA efforts. “All the discussions I hear about cloud are the same discussions we had about cloud four to five years ago,” she says. “How are applications in the cloud going to talk to the applications back home without intrinsic interoperability?”
I also had the opportunity to lead a panel discussion later in the day, joined by Anne, along with Microsoft’s John Devadoss (great to finally meet you in person, John!), Stefan Tilkov, and Clemen Utschig-Utschig of Oracle. Anne further elaborated on her thinking behind the “Dead” post, emphasizing her point that both end-user organizations and vendors are still too wrapped up in the idea of delivering some type of “SOA” package, versus delivering agility and flexibility. However, she noted, “Everything we do should be service oriented.”
Stefan Tilkov agreed with Anne on that point, but took issue on whether cloud computing represents some new phase of SOA. Cloud represents a different type of functionality and best practices, he emphasized.
I’m also part of the SOA Manifesto Working Group, which is meeting at the Symposium to draft a set of overarching principles to guide SOA efforts. We expect to announce the final document at the end of the conference — I’ll keep you posted.
October 9th, 2009
Gartner: You want cloud? You need SOA first
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.
October 6th, 2009
How to kick-start 'depressingly low' SOA service consumption
Has the time come for a change in the way we do SOA?
Dion Hinchcliffe, ZDNet’s resident Enterprise Web guru, has posted an interesting analysis of the state of service oriented architecture, and what it will take to kick-start it into the future. SOA has a couple of issues that is keeping it from reaching its potential, Dion wrote in new post over at ebizQ.
- First, the velocity of SOA seems too slow to keep up with the rapid changes buffeting organizations:
- Second, SOA service consumption remains at “depressingly low” levels;
- Third, SOA projects tend to be over-engineered.
What’s a beleaguered SOA proponent to do? Time to move to a new level, Dion says: Web Oriented Architecture. Dion calls WOA a “parallel track” for SOA that’s evolved in the more open Internet space, versus behind the opaque walls of corporate enterprises. Or as Dion puts it: WOA has grown “organically in the wilds of the online world to meet many of the same challenges that we have in our organizations today.”
Dion defines WOA in terms of open APIs, such as we see in cloud-based or Enterprise 2.0 services. WOA will help SOA reach its next level of performance. Ways we will see this evolve is the trend toward running SOA more like a business in itself; cheap, lightweight service delivery models; and access via REST-based interfaces and mashups.
The WOA approach makes a lot of sense, in no small part because of its relative simplicity and cost-effectiveness. SOA evolves from being an IT-centric megaproject to a series of initiatives in which business end-users can partake. Yes, there are many instances where iron-clad SOAP Web services are required. But everyone is already doing mashups, and the extended enterprise may benefit from the rise of WOA.
Dion will be talking about the SOA-WOA evolution at the SOA in Action conference I will be emceeing October 28-29.
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 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 15th, 2009
ESBs are patterns, not products
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 8th, 2009
Cloud may complicate SOA load balancing act
One of the major selling points of SOA and cloud computing is that service consumers don’t have to worry about the platform and hardware that the service is hosted on, be it somewhere else within the enterprise or maintained by an outside third party.
SOA’s greatest risk? Too much success, catching planners unprepared
Providers of services (and users), however, need to assure the availability of the service, and how much stress the underlying infrastructure can take as the service is repeatedly accessed. Lori MacVittie just posted a detailed analysis of the load balancing challenge associated with SOA-based deployments.
Lori cites a post by Stephan Koser, who provides a vivid scenario of what can go wrong with unbalanced SOA.
To function effectively, Lori observes, any load-balancing algorithm put into to place to assure availability and scalability of the service-delivery network be able to take into consideration the current load being handled by the particular server handling the request:
“This requires that the load balancer, the application delivery controller, be aware of the application, its environment, as collaboration well as the network and the user. It must be able to make a decision, in real-time, about where to direct any given request based on all the variables available. That includes CPU resources, what the request is, and even who the user/application is.”
However, when the cloud paradigm is introduced, this ability to see and monitor the systems providing services is, well, clouded over. If anything, Lori warns, cloud computing leads to poor visibility and renders load-balancing strategies useless. “The belief that the infrastructure should be ‘hidden’ from the user (that’s you) means that configuration options – like the load balancing algorithm – aren’t available to you as a user/deployer of cloud-based applications. Even though load balancing is going to be used to scale your application, you have no clue or control over how that’s going to occur.”
Lori very aptly points out that despite all the emphasis on virtualization, “applications are not islands,” and the ability to deliver and manage applications ” requires collaboration between a growing number of components in the data center.” Load balancing is a good start.
There’s plenty of talk about SOA failure, but, ironically, the greatest risk may come from too much SOA success. Organizations deploy shareable services, only to have them pounded into the ground by a growing number of requesting applications. Here’s a case where SOA costs may be driven up by the need to quickly put in or provision additional hardware. Cloud adds a new dimension to the challenge.
September 4th, 2009
Enterprise architecture pitfalls: the obvious, and beyond the obvious
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 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 17th, 2009
Another view: SOA is like a mosquito, spreading viral data
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 10th, 2009
Panel: too much to lose by moving to generic services and cloud?
Do we put competitive advantage at risk when moving to generic services? Or perhaps the whole scenario of enterprise IT being edged out by the cloud is overblown? Consider the the mainframe, as Dana Gardner recently put it:
“In the early 1990s, IT pundits, and my former boss Stewart Alsop, glibly predicted at InfoWorld that the plug would be pulled on the last mainframe in 1996. It didn’t happen. Stewart apologized, sort of, and the mainframe continues to support many significant portions of corporate IT functions.”
Do we put competitive advantage at risk when moving to generic services?
Why is the mainframe still alive and well? Because it has embedded within it competitive advantage — applications and processes no one else has. In the same spirit as the mainframe’s never-ending demise, many pundits now talk about the imminent demise — or greatly diminished footprint — of the information technology department or function, as organizations turn to cloud providers.
However, do companies risk giving up too much when moving to the cloud? As my fellow analysts put it, don’t be too quick to write off enterprise IT. As Sandy Rogers, who has been closely following the SOA and services space for a number of years, first with IDC and now as an independent analyst, put it, says organizations know they need to replace legacy technology, but fear they will lose too much value-add process and code in the process.
In a newly released podcast with Dana Gardner’s Analyst Insights group (transcript available here), Sandy points out that “many organizations have avoided legacy modernization projects due to the cost of change. It’s not just about the technology replacement. It’s a loss of capabilities,” she says. “It’s the change in human workflow and knowledge base.” The risk with cloud is that companies may end up replacing specialized technologies with generic solutions.
Data warehousing is another area not ready for the cloud, as explained by Jim Koblieus. Jim says there’s some talk of moving data warehousing to the clouds, but it’s still mainly talk. Maybe in a couple of years we’ll see something, probably in the form of some sort of cloud-based staging layer. “There aren’t a substantial number of enterprises that have outsourced their data warehouse or their marts,” he says. “Probably there aren’t that many commercial options yet that are fit to do so. Only a handful of data warehousing vendors offer a hosted solution, a SaaS, or cloud solution. I’ve been telling people that 2009 is not the year of the cloud in data warehousing, nor is 2010. I think 2011 will see a substantial number of data warehouses deployed into the cloud.”
What about applications? Tony Baer sees a mixed bag as far as application development or hosting from the cloud. “There is a degree of control that you like, but there are some tactical reasons,” he says. “When you’re developing code, you don’t want to have to deal with any type of network latencies that are going to come up when you deal with cloud. No matter how good the bandwidth, there are always going to be times when there are going to be some speed bumps. But, the other part was also related to IP, which is source code before it’s compiled in the binaries. It’s basically pretty naked and it’s pretty ripe for stealing. This is your intellectual property. Today, if you’re doing development, it’s because there aren’t packages that are available to supply a generic need. It’s something that’s a process that’s unique to your organization.”
Ron Schmelzer, on the other hand, says the economy has turned this era into a major inflection point, which we will someday look back upon and recognize as the beginning of the cloud era. “If you look at when most of the major IT shifts happen, it’s almost always during period of economic recession,” he points out. “The last time was in 2000-2001, when we first started really talking about service-oriented architecture. In the mid- ’90s was when we really started pushing out the Web. In the early part of the ’80s, when recession was kind of bad, that’s when personal computers started coming about.”
A lousy economy, with tight budgets, always spurs new ways of addressing technology challenges. And I agree, and pointed out many times in this blogsite, that the economic downturn of the early 2000s — which gutted many IT departments — gave rise to interest in Web services and SOA. But note that everyone didn;t stampede to SOA all at once — it’s been a long-term, incremental evolution that continues to this day.
Given this, nobody on the Insights panel was ready to write off IT anytime soon. As Brad Shimmin put it, IT may shrink a bit in some areas, but it’s not going to diminish in value. BBrad predicts that over the coming years, IT “is going to be very much alive, but the value is going to be more of a managerial role working with partners. The role is changing to be more of business analysts, working with their end users too. Those end users are both customers and developers, in some ways, rather than these guys just running around, rebooting Exchange servers to keep the green lights blinking.”
August 10th, 2009
SOA services: stop worrying about protocols, worry about the business
Richard Watson says there is too much hand wringing over service protocols and standards (REST, WS-*, etc.), and not enough thought given to why a service may be needed by the business in the first place. In a new post, he states that while “debates about whether to use REST or WS-* interface styles are seductive. But, these are the wrong questions to ask first.”
Instead, Watson urges the creation of services using a service model that will provide the business context to projects.
This is the essence of service oriented architecture, he says. “If context is not driving you to create the right services, then they are most likely not adding value to your applications architecture, they are making it worse.”
Build services that add value, he says. Forget about the protocol issues:
“Should I use WS-* or REST? Should a service provide access over HTTP, MOM, or XMPP? These are the wrong questions for architects to ask when first conceiving a service. By concentrating on how to build, we lose focus on what to build.”
Watson points out that when he talks about service modeling, he isn’t talking about things such as formalism, notation, and tools.
Service modeling is a smart idea for SOA environments because it encourages that services be mapped to business requirements, and not take on a life of their own as technology for technology’s sake.
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
- 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
- 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
- The True Costs of Virtual Server Solutions VMware In an economic environment that is repeatedly heralding the message "do ... 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
- Popping the buzzword bubble
- Panel: do cloud computing economic advantages break down in enterprises?
- No SOAP for this Navy
- SOA promotes a sea change for the US Coast Guard
- SOA helps Coast Guard navigate new tides of homeland security
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
- Gartner: 10 reasons why both sides of the SOA debate have it wrong
- Bridging the gap between BPM and SOA: look to the repository
- SOA promotes a sea change for the US Coast Guard
Top Rated
- No SOAP for this Navy+4 votes
- ARIN CEO reminds: be prepared for Internet numbering expansion+3 votes
- Popping the buzzword bubble+3 votes
- Survey: cloud interest grows triple-fold; cost may not be main factor+3 votes
- IT project risk aversion 101+3 votes
- Gartner: 10 reasons why both sides of the SOA debate have it wrong+3 votes
- SOA helps Coast Guard navigate new tides of homeland security+2 votes
- Bridging the gap between BPM and SOA: look to the repository+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 >>
- The more you simplify, the more you save
-
When you transition from your existing Red Hat environment to SUSE Linux Enterprise from Novell, you can recognize dramatic cost savings, perhaps as much 50%
- Learn more >>
- Reduce risk. Reduce complexity. Increase reliability.
-
A simplified IT environment isn't just less complex. It's also more reliable. Standardize on a single Linux platform with SUSE Linux Enterprise from Novell, and get the world's most interoperable Linux
- Learn more >>
- Keep Up With The Latest In Document Management with The DocuMentor.
-
Doc delivers the scoop on today's enterprise content management, printer maintenance, and all other issues related to document management. It's the DocuMentor Blog.
- Learn more >>
Archives
Favorite Links
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
- Unrivaled support from Novell, now available for Red Hat Novell If Linux is going to power your mission-critical applications, you'd ... Download Now
- Reducing Server Total Cost of Ownership with VMware Virtualization Software VMware VMware virtualization enables customers to reduce their server TCO and ... Download Now
- 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
Popular Sanity Saver Videos
