Category: Web 2.0-Enterprise 2.0
November 9th, 2009
Enterprise mashup, defined
Kudos to JackBe’s
You may recall that last spring, following a TV news interview, Luis was not happy with the explanation he gave to describe enterprise mashups. JackBe sponsored a couple of contests, along with a lot of discussion among practitioners and analysts.
Here, at last, is the working definition Luis and his team have arrived at:
“Enterprise Mashups are secure, visually rich Web applications that expose actionable information from diverse internal and external information sources.”
Wait — that’s not all. The JackBe crew also sought to answer the question of “why” people need enterprise mashups. They didn’t want enterprise mashups to be solutions in search of problems, as has been the case with many a technology initiative:
“Poor decisions are often made because decision-makers do not have the right information at the right time. Enterprise mashups deliver new insights and enable better decisions through personalized access to the right, real-time information for the specific problem at hand.”
And finally, the JackBe crew also addressed the “how” aspect — as in how enterprise mashups can be created:
“An enterprise mashup platform is a technology suite that enables the rapid, collaborative, user-driven creation of Enterprise mashups without the complexities, costs and risks of traditional information integration projects.”
In this last passage, the user-created aspect of enterprise mashups are included in the definition. This is where mashups can potentially deliver business benefits, as more flexibility can be put into users’ hands. And, as the “why” part of this definition shows, enterprise mashups put decision makers in touch with performance data from across the organization. The greatest challenge to delivery of information at this time is the time it takes to prepare and deliver reports. Let’s give end-users the tools to quickly and configure their interfaces to back-end enterprise applications and data.
October 26th, 2009
Survey: cloud interest grows triple-fold; cost may not be main factor
Everyone figures that companies are buying into cloud to save money. A new survey says otherwise. But why are companies adopting cloud?
A new study (PDF link) commissioned by Avanade shows a 320% increase over the past nine months in respondents reporting that they are testing or planning to implement cloud computing. Avanade claims this is the first time a survey has documented a global embrace of cloud computing in the enterprise.
The study also found that while companies are moving toward cloud computing, there is little support for cloud-only models (just five percent of respondents utilize only cloud computing). Rather, most companies are using a combination of cloud and internally owned systems, or hybrid approach.
Okay, the survey confirms what we’ve been seeing anecdotally. That is, there’s been a huge uptick in cloud interest. And apparently, this has been taking place during an economic downturn. But here’s where it gets interesting: Only 13% said the onset of a tougher economy helped push them toward the cloud. A majority, 58%, say economic conditions had nothing to do with it.
While Avanade didn’t seem to read anything into this, another observer, Paul Miller, thought this finding was a real eye-opener, suggesting that contrary to what everyone assumes, cloud computing decisions are not being driven by cost-cutting needs:
“Also interesting was the relatively small impact of the economic situation upon Cloud adoption, with only 13% suggesting it had ‘helped’ adoption plans and 58% reporting ‘no effect.’ In my conversations with Nick Carr and others, there’s been an underlying presumption (on my part, as well as theirs) that cost-saving arguments with respect to Cloud Computing would prove persuasive and compelling. It would appear not. This would suggest, of course, that enterprise adopters are taking to the Cloud for reasons other than the budget sheet…”
If it isn’t its low entry costs, then why is cloud computing so popular? Avanade says half of the companies surveyed that have migrated to cloud computing technologies use it to “manage and deliver business applications such as customer relationship management (CRM) and human resources (HR) services.” Forty‐six percent of respondents are also using cloud computing for data storage.
Speaking of greater flexibility and agility, the Avanade survey suggests that the service model is taking over as the prevailing IT value proposition. As Avanade puts it, the “online services model is beginning to fundamentally change how IT services are consumed and provisioned in large organizations. More than half of respondents report that they are currently using Software as a Service applications. In the United States, that number increases to more than two-thirds (68 percent).”
And many of these deployments are internal cloud. Avanade says that globally, “there is a 2:1 ratio of respondents who prefer SaaS delivered internally (or as private services) versus from third-party service providers. There is an even greater dissparity in the United States, with a 4:1 ratio in favor of internal SaaS deployments.”
October 21st, 2009
Gartner leaves SOA off 'top ten' list - again
Gartner just issued its Top 10 Technology list for the year ahead, and guess what’s missing? Once again, service oriented architecture got sacked by the sages of Stamford.
SOA proponents, however, can take cold comfort that just as was the case last year, SOA is the underpinning foundation and enabler of many of the Top 10 technologies. Cloud computing? You need a foundation to deliver those services across firewalls. Cloud also sucks in Web oriented architecture and enterprise mashups — prime SOA territory. Advanced analytics? They won’t be so advanced if data doesn’t get pulled out of organizational and system silos. Client computing? Enterprise mashups, anyone? And, hey, where is event processing?
October 15th, 2009
Conference alert: let's make SOA work for a living
Welcome to Service Oriented Architecture, Phase 2. It’s bigger, It’s badder, it’s all business. None of this namby-pamby JBOWs stuff. None of these SOAPY-REST tantrums. SOA is all grown up now, and it’s time it starts earning the bacon.
I am serving as conference chair and emcee for ebizQ’s upcoming “SOA in Action” virtual conference, scheduled for October 28th and 29th, and want to share some of highlights with you.
I will be joined by a number of leading industry figures in various sessions and panel discussions, including Forrester’s Randy Heffner, Software AG’s governance guru Miko Matsumura, Web Oriented Architecture guru Dion Hinchcliffe (also a rock star here at the ZDNet community), Gartner’s Yefim Natis, captain of the cloud Dave Linthicum, and US Department of Defense CIO Dan Risacher. The conference will be capped by a joint session featuring Gartner’s Roy Schulte and CalTech’s Mani Chandy.
Some author notes: Roy Schulte and Mani Chandy have just published a new work on event processing, Event Processing: Designing IT Systems for Agile Companies. Dave Linthicum has just published his latest book, Cloud Computing and SOA Convergence in Your Enterprise: A Step-by-Step Guide.
Topics to be discussed include organizational and governance issues, “selling” SOA’s value to the business is more difficult in today’s economy, ROI, complex event processing, and cloud computing.
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 25th, 2009
XML on the wane? Say it isn't so, Jack
Jack Vaughan has got things all abuzz with a recent post that ponders whether XML’s best days are behind it.
Is the ‘X’ in Ajax (Asynchronous JavaScript and XML) fading?
With the growing popularity of Rich Internet Applications an enterprise mashups, it’s conceivable that we may see less and less XML, Jack speculates. “Like Pick or Fortran or other once-popular languages, it is conceivable that XML’s use will at some point decline.”
For example, he quotes Yahoo Architect and JSON originator Doug Crockford, the original developer of JSON (JavaScript Object Notation), who says the protocol “was a reaction to complexity arising around XML. Such complexity did not make sense in simple Web applications.”
Many applications written in Ajax (Asynchronous JavaScript And XML) “never go near XML,” Jack adds. As he puts it: “The ‘X’ in Ajax is fading. Some would say Ajax and XML have forked. At the same time, those simple Web apps are growing in complexity.”
I don’t know if XML would ever go the way of Fortan or Pick, since these are programming languages, and XML is a meta language used in conjunction with programming languages. XML is at the foundation of many integration efforts, Web services, and SOA projects. We finally have something that’s bringing together all the world’s systems and data. I have a feeling there will be lots of XML around in the years to come. But, as Jack reminds us, nothing is invincible — not even mighty XML.
September 24th, 2009
Enterprise mashup proponents start organizing
As reported a couple of days ago, the enterprise mashup market promises to be a huge one, growing to almost $2 billion in a few years. So it’s high time people involved in this space start organizing and working around some standards everyone can agree on.
Can enterprise mashup proponents avoid the mistakes made with ESBs?
A new consortium, called the Open Mashup Alliance, is the first effort to coalesce around this growing phenomenon. The group’s stated mission is to promote “the successful use of Enterprise Mashup technologies and adoption of an open language that promotes Enterprise Mashup interoperability and portability.”
One of the founding members is ZDNet’s resident Enterprise Web 2.0 guru, Dion Hinchcliffe. Additional charter members include Adobe, Bank of America, Capgemini, HP, Intel, JackBe, Kapow Technologies, ProgrammableWeb, Synteractive, and Xignite.
One of the OMA’s first endeavors is to shepherd the budding Enterprise Mashup Markup Language (EMML) specification for submission to a standards body. EMML is an XML-based, domain-specific language that was designed to address the characteristics that make mashups easier to create and reuse.
There were a bunch of supporting quotes included with the OMA’s announcement, but I think Michael Ogrinz, principal architect at Bank of America and author of the book Mashup Patterns, said it best: “For enterprise mashups to take hold, we need to remove the ‘vendor lock-in’ concerns raised by today’s proprietary toolsets. We also need to inspire the innovative minds of the open-source community to start working in this space. By establishing an open standard for mashups, the OMA and EMML addresses both of these issues.”
Perhaps the industry learned some lessons from another development that proliferated without guiding standards — the enterprise service bus. One of the fiercest criticisms of ESBs has been the way vendors took off in all different directions with their implementations before standards could be established. Perhaps we can avoid this with enterprise mashups. But the looming market size must be a huge temptation.
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
Enterprise mashup market to increase tenfold over next five years
A new report from Business Insights predicts that the enterprise mashup market, worth around $161 million in 2008, will expand more than tenfold to $1.74 billion by 2013.
About 33% of companies now use enterprise mashups, Business Insights says.
The catalyst for the enterprise mashup market will be SOA — Business Insights puts the SOA platform market at about $1.4 billion in 2008, which will double in size, to about $2.77 billion by 2014.
It’s interesting that the enterprise mashup market, which currently is about 11% the size of the overall SOA platform market, will soon be 63% the size, or getting close to comparable. This is huge for the front-end part of the equation, if these numbers pan out. But does it make sense?
September 21st, 2009
Cloud offers SOA apps a 'venue to stretch their legs'
“Cloud computing is already beginning to unleash the potential of SOA and much more is on the way.”
Cloud is the target platform SOA has been lacking until now
That’s the view of Gray Hall, a veteran of the IT hosting industry, in a recent post on the growing role of SOA in cloud formations. Gray states that SOA is an architectural pattern and cloud is a target platform for that pattern. The significance of cloud, he adds, is that SOA has languished since its inception, and the reason is because it has lacked a “target platform.” As he puts it:
“[It] is correct to call SOA an architectural pattern. [It] is correct to call cloud computing a ‘target platform.’ But the real news in this story is that a target platform is exactly what SOA has been lacking all these years. All applications must run somewhere; applications need infrastructure. SOA is an application architecture; cloud computing is an infrastructure architecture. It’s that simple. This marriage is long overdue.”
Gray says that cloud processing (dynamic allocation of CPU resources) and cloud storage (Web services API access to storage resources) infrastructure “is the most natural target platform for SOA apps because cloud infrastructure is designed to scale in the way implied by the SOA approach to application architecture.”
Cloud infrastructure services such as Amazon Web Services and Rackspace have made SOA real to many companies, he says. “Until recently, where could a SOA app find a venue to stretch its legs?”
Gray has hit upon something here. SOA’s value is not seen within services built for a single silo, or even those shared between two or more silos. SOA begins to pay off as the result of a network effect — services built and consumed across a growing Web of providers and consumers. Cloud-based services are broadening organizations’ vistas as to when and where they can access services.
(Thanks to reader csarkar for the pointer to Gray’s post.)
September 21st, 2009
Twenty percent of SOA value from service reuse; where's the other 80%?
Is service reuse a worthy part of the SOA value equation? This is a question that has been endlessly debated in recent years.
Mashups may hold the key to long-term SOA value
For example, last month, we quoted Forbes’ Dan Woods, who argued that companies are focusing on building SOA-based services that will be available for reuse as soon as they are tested and released to the registry/repository. Perhaps, he says, we should worry less about reusability at the beginning phase of service development.
Or, even if reuse does deliver ROI, it may only have a limited reach. Marc Rix recently weighed in on the topic, suggesting out that “basing SOA on reuse only modernizes 20% of IT and, thus, does not yield agility.” The other 80% of the equation, he says, is based on deployment of data services.
He arrived at the 20% figure by calculating the fact that reusable services tend to be the most popular or mainstream services, and “tend to orbit around relatively static business data (employees, customers, vendors, suppliers, etc.).” Building and deploying these services means relatively immediate reuse, and therefore, ROI. However, there’s little ROI beyond the immediate rush, he says.
For SOA value, Marc says, look to the ” Long Tail of IT” — data taken out of core enterprise systems and manipulated by business users, in applications such as business intelligence and analytics. “This is where business is really conducted and this is where SOA is really needed,” he says.
Why I hear Marc saying is the real meat of SOA will be seen in more dynamic, user-created (or at least user specified) composite apps. Enterprise mashups come to mind in this context. In these situations, end users can create their own interfaces as business requirements demand. They can be quickly built and used. However, what is needed is a way to make this possible within a governed framework. With SOA governance and best practices applied on this end at the architectural level, organizations have assurance that these enterprise mashups are subject to the same security and vetting as core SOA services.
September 16th, 2009
First there was WS-*, now we have REST-*
Should we call it “REST-star” or “REST-splat”?
Paul Krill reports that Red Hat has launched a community-based standards set it is calling REST-*, which could serve as a counterpoint to the WS-* specifications for Web services. Red Hat says it hopes to work with major vendors such as IBM and Microsoft, “to define standards or recommendations for REST-based system integration.”
Mark Little, CTO of JBoss/Red Hat, announced the new initiative at the recent JBoss World conference in Chicago, noting that the WS-* series of Web services have become complex. “Maybe REST is a better way of doing certainly Internet-scale integration, but one of the problems of REST is it lacks clear guidelines,” for enterprise capabilities, such as security, transactions, and high availability.”
Red Hat even now has a home page for the REST-* effort, which outlines the vision, specifications, and community for the standards set.
Red Hatter Bill Burke makes the case for REST-* thusly:
“While REST has gained huge momentum in the SOA community, there hasn’t been a lot of standardization of traditional middleware services. The REST-* community aims to introduce new REST-based standards for these traditional services where none exist and provide well-defined guidelines where protocols do exist.”
There are two efforts now underway as part of the REST-* set:
REST-* Transactions: A specification that attempts to define a RESTful interface for transactions. “It describes the interaction between coordinator services and transaction participants as well as how transactions can propagate in distributed applications. It defines both a 2-Phase-Commit model as well as a Forward-Compensation protocol.”
REST-* Messaging: Messaging encompases publish and subscribe and point-to-point protocols. This specification defines a RESTful interface for queues (p2p) and topics (pub/sub).
Not everyone is welcoming the new initiative with open arms. Anne Thomas Manes, for one, says she’s “got a bad feeling about this.” She points out that REST-* may stray from REST principles, and “you won’t attain the desirable RESTful characteristics (scalability, serendipity, network effects, etc) that REST is supposed to enable.”
“A more useful effort would be one that defines RESTful patterns that support and enable mission-critical capabilities like reliable delivery, transactional integrity, and the like. But please, let’s not reinvent CORBA on REST. Here’s hoping the whole REST-* thing just dies out.”
Sure, mistakes were made with SOAP and WS-*, and Burke admits that “blind idealism,” combined with Red Hat’s experience with communities, will guide this latest effort past obstacles, complexities, and pitfalls. Red Hat is “jumpstarting and founding the standards body itself,” and is “battle tested in specifications efforts at the JCP and other bodies.” Burke adds that “we’ve often been frustrated by the closed and inflexible attributes of these organizations. We feel our open source roots and ideals make us an excellent candidate to drive and host standardization efforts.”
September 3rd, 2009
Enough of RESTless SOA? Speak now or forever hold your peace
Speak now or forever hold your peace…
Has anyone ever actually heard someone disrupt a wedding ceremony by voicing an objection to the proposed union?
Has anyone ever heard someone object to an SOA plan because its based on SOAP, and not enough REST?
In an interesting new post, Justin Cormack says not enough people speak up when corporate decisions are made to adopt of SOAP-base Web services as the foundation of SOA, before the deal is sealed and things really start to get messy:
“I went to a meeting a while back with a company starting to move to a Web service based, internal API based architecture, and there was a minute where the CTO said (more or less) “does anyone know of any let or hindrance to this being a SOAP API?”. Like those moments at weddings, no one spoke out. But I do object. SOAP is not the backbone of a happy architecture, but we do not have the strength to say no right now.”
Justin says this is the time for enterprises to move from SOAP to REST, and transition their service oriented architecture (SOA) to a resource oriented architecture (ROA).
Not a bad nomenclature — and he makes his case for a RESTful ROA:
- Web developers favor REST. “It is more productive. It does not involve programs to generate huge chunks of useless code. It involves hypertext, not opaque documents that are mappings of database schemas.”
- REST is less expensive, as it requires fewer application development resources.
Look at modeling systems as resources, Justin continues. “Resources are much easier to work with than services, as they share uniform semantics, and they are addressable, two keys to making application design simple.” A CRM system is an example of something that needs to be modeled as resources, he says. “You need API calls that can find products a customer has bought, support tickets, all the core data that you would need to build customer service portals, internal support applications.”
REST enables a resource oriented architecture based on HATEOS or Hypertext as the Engine of Application State. HATEOS “involves is moving the vague and very expensive field of business logic from code (often code that is not even owned or understood by the enterprise, as it has been embodied into code written into systems from suppliers) into hypertext documents,” Justin explains.
Thanks to Dilip Krishnan for pointing to this post.
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 14th, 2009
Gartner: SOA out of 'trough of disillusionment,' cloud on hype peak
Gartner recently released its latest “hype cycle” diagram for 2009, which shows service-oriented architecture to be well past the “trough of disillusionment” and climbing the vaunted “slope of enlightenment.”
Cloud computing, however, is now at the pinnacle of hype (no surprise there, right?), and ready to plunge into the trough. Interestingly, Web 2.0 now seems to be emerging from the disillusionment trough.
Being on the slope of enlightenment is typically the stage where vendors, analysts, and pundits are no longer gushing about how wonderful and world-shattering the technology/methodology is. Nor are they ranting on about what a flop the thing is. Instead, it’s the roll-up-your-sleeves stage, when companies and their technology professionals are getting down and making the stuff actually work.
Next stop: The “plateau of productivity!”
Source: Gartner (August 2009)
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.”
July 12th, 2009
In praise of 'slow IT'
Common wisdom says that an engine running in overdrive for an extended period of time will overheat and break down. People driving themselves too fast and hard risk breakdowns or health problems.
David Sprott recently posted an interesting piece on the need to slow down the blistering pace of IT projects. He takes a page from Carl Honoré, who advocates a “slow movement,” which says perhaps some things can get done better at a more deliberate pace.
David ponders whether the blazing-fast pace of unfettered offshoring, agile development adopted purely for speed is compromising architectural principles in favor of short-term gains. Has the time come for Slow IT?
In a post late last year, Ron Tolido coined the phrase “Slow IT, the art of careful technology,” noting that perhaps there is a backlash brewing to the hectic, real-time emphasis on get-it-now IT:
“It is about using the principles of Enterprise Architecture to create a platform for continuous business change. This is not a paradox: only on top of a simplified, secure and flexible foundation of building blocks we can orchestrate and change solutions on a daily basis. On-the-fly processes, instant collaboration, mashups and real-time intelligence: we definitely need them to deal with the hectic business requirements of today and tomorrow. But not in a breathless, ADHD style that quickly will only agitate us more. Instead we need the confidence that we took exactly the right time and dedicated exactly the right focus to create a true architecture for change.”
With Slow IT, Ron foresees “a renewed respect for properly timed and crafted technology solutions.” Plan things out well, and let the fast-paced stuff move in and out as required.
Hence the fact that we need enterprise architecture to provide a way for organizations to catch their collective breaths and think about what technology needs to be implemented, and how it will serve the business. And SOA itself is such a long-term, deliberative process.
As David puts it: “I am completely with Ron in rejecting the superficial - Web 2.0, panic package acquisitions and the like for use in serious enterprise business processes. Yes we need to transition enterprise systems to modern componentized architecture that permits continuous upgrade of smaller moving parts.”
Ron Tolido just wrote a follow-up piece endorsing David’s thoughts. He also clarifies that Slow IT doesn’t necessarily mean “doing things at a snail’s pace, doing less or doing nothing at all. Remember: it is all about proper timing and focus. Eating Slow Food does not mean waiting for hours until the waiter arrives or the first course is served.”
He repeats David Sprott’s mantra of injecting “repeatable, reusable and rapid” solutions into IT operations. In other words, “carefully craft a foundation for continuous change.”
July 7th, 2009
Services that scale: the 'intercloud' emerges
When clouds go global and services are shared across multiple time zones, perhaps that heralds the emergence of a new structure. Some have taken to calling this global confederation of services the “intercloud.”
Shades of the Internet, the network of networks. In a new post, Lori MacVittie provides a description of the intercloud:
“The intercloud is the natural evolution of global application delivery. The intercloud is about delivering applications (services) from one of many locations based on a variety of parameters that will be, one assumes, user/organization defined. Some of those parameters could be traditional ones: application availability, performance, or user-location. Others could be more business-focused and based on such tangibles as cost of processing.”
We had a similar discussion at a BriefingsDirect panel a few months back, in which we debated who or what would be joining forces to offer comprehensive cloud-based services. Dana Gardner and other analysts speculated that many of the large infrastructure vendors would be banding their partner ecosystems into large cloud combines.
Pushing services out into the world to anyone anywhere who needs them just won’t happen by magic, of course. Lori talks about “global load balancing” in her posts, which fits into the context of the intercloud. “What I find eminently exciting about the intercloud concept is that it requires a level of intelligence, of contextual awareness, that is the purview of application delivery,” she points out. These applications being delivered across the intercloud are even being called “services” again, a la SOA, she points out.
The challenge is that “intercloud requires a bit more awareness than global application delivery; specifically it requires more business and data center specific awareness than we have available,” she adds. Emphasis on the business part of the data. This requires automation — to try to configure a global application delivery system manually would be tedious beyond tedious.
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
- The True Costs of Virtual Server Solutions VMware In an economic environment that is repeatedly heralding the message "do ... Download Now
- Five Steps to Determine When to Virtualize YourServers VMware Server virtualization isn't just for big companies. Entry-level ... Download Now
- The Impact of Virtualization Software on Operating Environments VMware Today's use of virtualization technology allows IT professionals to ... 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
- Gartner: 10 reasons why both sides of the SOA debate have it wrong
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
- 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
- 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 >>
- 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 >>
- 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
- Building the Virtualized Enterprise with VMware Iinfrastructure VMware VMware virtualization software has been adopted by over 120,000 enterprise ... Download Now
- Five Steps to Determine When to Virtualize YourServers VMware Server virtualization isn't just for big companies. Entry-level ... Download Now
- Email Security and Archiving - Clearer in the Cloud Google The time is NOW for businesses and organizations of all sizes to implement ... Download Now
-
-
Smart Tech
Expert advice on innovations in healthcare and the green technologies that make it happen.
Find out more
-
Smart Business
Discussion and advice on management issues that revolve around making your world smarter and more useful.
More Smart Advice
-
Smart People
The best and worst moves in the management and strategy trenches.
Learn More
