September 6th, 2008

The WOA story emerges as better outcomes sought for SOA

Posted by Dion Hinchcliffe @ 2:04 pm

Categories: ATOM, Ajax, Business Models, Customer Self-Service, Encouraging Unintended Uses, Enterprise Mashups, Enterprise Web 2.0, Global SOA, Governance, JSON, Lightweight Service Models, Mashups, Network Effects, Network effects, Open APIs, REST, Radical Decentralization, Rich Internet Applications (RIA), Right To Remix, SOA, SOAP, SaaS, Small Pieces, Loosely Joined, Tolerance Continuum, Web 2.0, Web as Platform, Web services, Web-Oriented Architecture (WOA), Widgets

Tags: Web, Business, SOA, Organization, WOA, WOA Story, REST, Service-Oriented Architecture (SOA), Web Services, Middleware

Over the summer the enterprise IT blogosphere was swept up in a conversation around the concepts that many are calling Web-Oriented Architecture, or WOA. A different way to think about service-oriented architecture, WOA extolls a different but related set of technologies, in particular how to apply them in specific ways to connect our systems together into the solutions we need to take on our daily business challenges. WOA offers the exciting and fast-growth promise of the Web 2.0 world, while SOA has been seen as struggling and encountering low engagement in most organizations.

For those just joining the conversation, SOA is the most common set of top-level organizing principles and technologies that enterprises use to organize and connect their IT systems. However, SOA is increasingly in the firing line for less-than-stellar results and lack of business alignment. Few promising solutions for this have emerged lately, with the increasingly notable exception of WOA. WOA describes a compelling new focus that can address many existing SOA issues, but is sometimes at odds with traditional IT and business thinking.

Along with different technology emphasis, WOA offers a compelling new perspective on service uptake and consumption and offers potent ways of thinking about business models that can directly drive innovation and growth. Even better, we can now point to existing WOA success stories, albeit most of them in the online world. In short, SOA (of which WOA is a part) hasn’t looked this interesting in years. But like most new ideas, it inevitably faces challenges from the old guard.

For its own part, far from being a boring, back-office story about plumbing and infrastructure, SOA has actually seen better results than most of the enterprise architecture models that came before it. However, these returns have been fairly lackluster compared to what most business were actually looking for and what SOA practitioners wanted and were actively trying to achieve, certainly when any measurements of the ROI were taken. My detailed WOA overview last April tells the story: The Burton Group ultimately concluded earlier this year that “that SOA is not working in most organizations” based on extensive conversations with clients.

I’ve covered this territory a number of times in the past, most notably with an in-depth exploration of What is WOA?, but the story remains the same: WOA is being driven by the widespread success that lightweight Web services — and particularly their use in open APIs — are having on the open Web. The broad lesson that has been dawning on the enterprise architecture world this year is that this is what’s actually working in terms of what SOA has been trying to accomplish, but with a uniquely different approach.

Explore several WOA success stories and how they are driving SOA.

The tide seems to be turning in terms of the industry’s perspective of WOA as well. Respected SOA expert David Linthicum recently asked “SOA out, WOA in?” and seemed to think it was, noting it will take a long time, like SOA did, to make inroads in the enterprise despite its widespread adoption on the Internet. ZDNet’s own Joe McKendrick recently noted that “WOA wins hands-down over SOA in popularity contest” and Dave Rosenberg recently discussed WOA on CNET and took it as a forgone conclusion. And this is a key point: Many organizations I talk to are already using some WOA to some degree on the ground today, it’s just not being promoted like traditional SOA is, thereby missing the benefit of the support, documentation, guidance, management, and infrastructure/tools support needed to fully flourish.

We have started to see traditional organizations begin to offer WOA-friendly services to the world at large. For example, the World Bank recently opened its Web API to developers using the increasingly popular Mashery service, which allows an organization to outsource their WOA. Of course, WOA can be used solely inside the firewall but some of the most interesting scenarios involve integration with business partners, on demand in a very agile, lightweight fashion.

And in the end, this is the challenge. The use of WOA on the technology side is only interesting if there is support for the business for the scenarios it encourages. You could convert all your Web services from SOAP or REST and be fully ready for the resulting stream of consumer and enterprise mashups, API customers, and hundreds of new business partners, but not if you’ve not redesigned your business a bit. This is also one key reason WOA isn’t synonymous with REST. WOA is architecture, both technical and business, while REST is a style building WOA services. The implications of WOA also go beyond REST to include other Web-oriented scenarios such as widgets, browser-based interfaces, and so on.

WOA entails both technology and business change

Unfortunately, many businesses have not yet absorbed the lessons of the Web 2.0 era and still look at the Web simply as a way to deliver Web pages. This limited view and understanding of the Web’s potential means that most organizations do not have it on the radar to link themselves together in the enterprise-wide and Web-wide ecosystems of creation and integration that WOA can enable. SOA has always been about connecting systems and people together and — at long last — we have a clear path to potentially wonderful outcomes in terms of unintended uses. This includes the ability to access business opportunities inside of time windows which would previously have been unattainable with our traditional, heavyweight SOA models. But only if we truly change the way we think about how to leverage the network.

One last thing, it’s important to remember that no small system can sustain contact with a large system for very long without being fundamentally changed by it. This is what is happening with businesses (the small system, no matter how large) and the Web today (the big system.) The intrinsic nature of the Web is driving major changes in how we create network-based products and services and is inexorably turning us into Web-oriented businesses. Businesses that want to be successful on this network without understanding its fundamental nature and capabilities are only delaying the time it takes to reach the full potential the Web offers.

In this way, WOA often describes network business models (such as open Web APIs) that often seem very foreign to non-Internet businesses but are powerfully aligned with the way that the Web works. These models are almost certainly essential to be successful and flourish in the modern competitive landscape on our networks today. In this way, too many organizations will ignore adding a WOA aspect to their SOA work until it’s too late and the ability to generate strong network effects in their industry is greatly reduced.

WOA is just one of a set of transformative new distribution models for network-based systems.

So how do organizations start down this route to investigate the WOA way of doing SOA and seeing if it works for them?

Like many aspects of Web 2.0, WOA is not complex or overly expensive, it’s a way of thinking about interacting over the network and all the classic SOA principles still apply, which just create and expose them differently.

1. Learn about WOA. Study the technology (HTTP, REST, syndication, open Web APIs, widgets, metadata documentation, Ajax, mashups, JSON, etc.), as well as the business and implementation side, including partner ecosystems, developer support sites, monetization, and chargebacks.
2. Adapt WOA to your organization. Every organization will have a landscape of existing SOA approaches and technologies that WOA approaches will need to be added to. Furthermore, WOA does little good unless you’re willing to use it for what it does well: Provide the fuel for RIA-powered portal applications, enterprise mashups, your public APIs, and so on. Begun working through how WOA security will work in your organization (inline or through HTTPS, for example) and other key starter issues that are (hopefully) already described in your SOA governance documents.
3. Conduct a pilot. Validate the items in #2 with a small pilot. Select a mashup platform that works well for your organization and try it out. WOA enables SOA to be used in a much more agile, open, and effective manner, with the right tools involved but only in an environment that supports it all the way through the “stack” from browser, server, database, development tools, and management infrastructure.

What are your thoughts on WOA? Will this finally be where the rubber meets the road for many SOAs?

May 14th, 2007

Mashups: The next major new software development model?

Posted by Dion Hinchcliffe @ 12:05 pm

Categories: Ajax, Badges, Blogs, Business Models, Business Process Management, Collaboration, Enterprise 2.0, Enterprise Mashups, Enterprise Web 2.0, Enterprise Wikis, Gadgets, Global SOA, Lightweight Service Models, Mashups, Open APIs, Products, RSS, Rich Internet Applications (RIA), SOA, SaaS, Small Pieces, Loosely Joined, Social Software, Tolerance Continuum, Web 2.0, Web as Platform, Web services, Web-Oriented Architecture (WOA), Widgets, Wikis

Tags: Software, Web, Software Development, Mashup, Dion Hinchcliffe

At last week's Mashup Ecosystem Summit held in San Francisco and sponsored by IBM with an invited assemblage of leading players in this space, I gave an opening talk about the current challenges and opportunities of mashups.  And there I posed the title of this post as a statement instead of a question.   The reason that it's a question here is entirely driven by the context of who is currently creating the majority of mashups these days.  Because even a cursory examination of what people are doing every day on the Web right now tells us that mashups — also known as ad hoc Web sites created on the fly out of other Web sites — are indeed happening in a large way, albeit in simple forms, by the tens of thousands online every day. 

The consumerization of the enterprise as younger workers bring their Web 2.0 skills and habits to work has already begun.But inside our organizations, both in the IT department and in business units, mashups are a much rarer phenomenon.  And in fact, this is one of the classic hallmarks of the Web 2.0 era; the much larger community of the Web as a major source of innovation and leading edge behavior that subsequently moves across the firewall and into our workplaces.

However, the topic of this blog is aimed at the application of Web 2.0 to the enterprise and so whether mashups will be a significant new model for application development inside our businesses anytime soon is still somewhat of an open question.  It's worth noting that McKinsey's recent global executive survey of Web 2.0 in business said that a whopping 21% of large businesses across the board are planning investment in mashups in 2007, but a sobering 54% of business executives also said mashups were not even under consideration.  Understanding the timing on mashup adoption therefore is important along with the challenge of communicating their potential.

Since the mashup story is primarily being driven by spontaneous activity at the edge of the Internet, an accurate and updated picture of what's actually happening with them is harder to make out than if it was being driven by a centralized industry effort.  And as it turns out, this makes what's happening richer and more exciting than it would be otherwise while at the same providing significant challenges for those that want to take these compelling ideas and apply them deliberately to solve business problems.

So in the interest of making sure we have the broadest industry discussion we can about mashups — and to make sure there is some kind of snapshot of what we think we're seeing in this space — I thought I'd summarize the notes from my talk at the Mashup Ecosystem Summit.

To bring folks that are just joining the mashup conversation up to speed on why mashups are so exciting, I'll start with my take on the key aspects of mashups from a value proposition perspective.

Key Aspects and Benefits of the Mashup Approach

• Effective leverage of Web parts and the Global SOA. Mashups are generally built out of the bits, pieces, and services of other Web applications that already exist, adding code only when it can't be sourced from internal or external suppliers or to provide integration "glue" between the parts.  This reuse can quickly and easily leverage millions of dollars in previous investment and results in a

Read the rest of this entry »

June 18th, 2006

Is IBM making enterprise mashups respectable?

Posted by Dion Hinchcliffe @ 9:24 am

Categories: Ajax, Business Process Management, Customer Self-Service, Enterprise Mashups, Enterprise Web 2.0, Global SOA, Governance, Lightweight Service Models, Mashups, Products, RSS, Rich Internet Applications (RIA), Right To Remix, SOA, SOAP, SaaS, Small Pieces, Loosely Joined, Tolerance Continuum, Web 2.0, Web services

Tags:

ZDNet blog colleague Joe McKendrick beat me to the punch earlier this week with an excellent analysis of the fascinating ramifications of IBM’s recent statements at the New York PHP Conference aimed at mainstreaming mashups and Web 2.0 technologies.  If IBM is getting seriously involved in this, there must be something to it, and certainly Rod Smith’s comments are receiving considerable attention.

Interestingly, most enterprises I talk to these days barely have mashups on their radar, yet I also continually hear from those same folks about how hard it is to create increasingly integrated business applications, as well as the slow pace of rolling out new functionality to users and customers.  There indeed seems to be a rising corporate appetite for faster, more effective ways of building applications particularly when reusing existing IT software and information assets.

 

Despite all the attention in leading edge tech circles, there is still a general lack of knowledge about what mashups are, never mind so-called enterprise mashups, the unique obstacles to which are articulated succinctly here by Phil Wainewright.  The question I get asked most frequently about this space, however, is what the exact difference is between composite applications and mashups.

One big difference? Composite applications – those supposedly elegant marriages of the resources of a SOA into brand new software that is more an assembly of existing components than "green field" development – don’t have to be

Read the rest of this entry »

May 23rd, 2006

Does Java EE 5 getting REST mean WOA will break out?

Posted by Dion Hinchcliffe @ 5:08 pm

Categories: ATOM, Enterprise Web 2.0, Global SOA, Lightweight Service Models, Products, REST, RSS, SOA, SOAP, SaaS, Small Pieces, Loosely Joined, Tolerance Continuum, WS-*, Web 2.0, Web as Platform, Web services, Web-Oriented Architecture (WOA)

Tags:

The REST vs. SOAP debate can seem like an esoteric discussion about Web services, but it’s not.  REST puts the Web back into Web services by taking what’s been so successful with the fundamental protocol of the Web, namely HTTP, and making it into a seemingly ideal Web services architecture.  This model has been called Web-Oriented Architecture in certain quarters, and the label does seem to fit. REST, and its little brother, XML over HTTP, have increasingly gathered mindshare lately by sheer Darwinian competition.

SOAP is an a priori concoction created early in the life of the Web, while REST is a natural extension of that most successful Web services protocol of all time, HTTP. And now, like so many things lately, best practices from the Web, such as REST, are flowing back into our enterprise architectures and related products.  And for good reason.

For example, the new Java EE 5 (good coverage of this release by ZDNet’s Joe McKendrick here) now significantly includes built-in support for REST.  Unfortunately, J2EE expert Richard Monson-Haefel has a raft of concerns about JAX-WS 2.0 (the actual name of the new Web services support in Java EE 5), specifically about the dizzying complexity required to implement it.  This is genuinely unfortunate because REST has some extremely powerful capabilities to bring to the table and Java is one of the most heavily used enterprise platforms in history.  REST’s ease-of-consumption, interoperability, and performance – all due to its simplicity and true harmony with HTTP – are its most important attributes, but this can potentially be undone by excessive cruft.

Read this distilled overview by Doug Kohlert to see what it looks like to develop a simple number adding REST service with JAX-WS 2.0 in Java EE 5.

We get into Web 2.0 territory with the REST/WOA discussion when we talk about turning applications into platforms.  Specifically, this means

Read the rest of this entry »

February 14th, 2006

The power of simplicity at the edge

Posted by Dion Hinchcliffe @ 2:36 am

Categories: JSON, Lightweight Service Models, Mashups, Products, REST, RSS, Right To Remix, SOA, SOAP, Tolerance Continuum, Web 2.0, Web services

Tags:

One of the demonstrations I like to give to show the power of simple services is to use Iridesco’s Suprglu to instantly wire together Web services into a new and useful service on the spot.  This is the simplest possible mashup you can create but it does combine useful data from multiple sources into a single view.  You can do it yourself: copy and paste a few feeds from a few sources of interest and you’re off and running. 

Every decision to add unneeded structure or ceremony to the consumption of data in your organization is a tax that reduces the value that data offers.

This visceral demonstration shows the promise of using simple data formats like RSS to let anyone create useful new information sources and services in a straightforward manner.  I say services because Suprglu converts the resulting mashup into yet another RSS feed that can in turn be used and recombined anywhere on the Web.

In fact, service recombination, mashups, and remixing are going to force a lot of us to rethink our existing services to enable a composable Web. So too will the scalability, reliability, feedback loops, and the associated intellectual property issues, of the nascent remix culture.  Rethinking is necessary because so much of our approach in the IT world is still mired in the world of intended uses.  As we all know, most software in the enterprise is designed for specific requirements defined well ahead of time.  While service-oriented architecture (SOA) finally encourages second-order uses of services, I would suggest that this encouragement is just not forceful enough.

Note that Web 2.0 and SOA are primarily concerned about the edges of systems.  This could be the experience edge where the user interacts with with software, typically HTML, Ajax, Flash, etc.  Or it could be the services edge that provides pure information to other systems, such as HTTP, REST, RSS, and SOAP.  What happens inside isn’t revealed, nor should it.  This is the separation of interface from implementation that we’ve tried for so long to achieve.  And since software is increasingly made from pushing these edges together, we should seek to understand the best ways to do that.

Like agile software development discovered,

Read the rest of this entry »