Mashups Are About Assembly. SOA is about Integration

June 6, 2008

Anyone that thinks that eye-candy mashups created by users ‘at the glass’ is the beginning of the end for IT Departments is mistaken. Realistically, such mashups will only allow users to assemble – not integrate. This is a subtle but important distinction.

A good example that illustrates the difference between assembly and integration is the good old Lego block.

The size and shape of Lego blocks didn’t happen by accident. They look the way they do because someone made a conscious decision that the chosen design would maximise flexibility. The company knew that they could use the same base set of blocks and combine them into an endless array of products. What’s more, buyers could build things that the Lego company hadn’t even thought of.

What’s this got to do with mashups and SOA?

When we build an SOA we build a range of services that all conform to a particular design or standard (i.e. shape of the Lego block). This is easier said than done. Building these services takes a lot of thought and a lot of work. Integration is hard.

When we’ve designed and built our services (blocks), we don’t stop there – we then combine (or package) those services into a useable product (i.e. Lego block set) that someone will actually use – for example composite applications or portals.

And here’s where it gets interesting. Users can use the product we’ve produced or they can take our base services and re-assemble them (mash them up) in any way they choose. Probably in ways that we hadn’t even thought of.

So, IT has done the hard integration work and designed the blocks in a way that will make them flexible and re-useable. The business can then take those building blocks and do whatever they like with them. Everyone is happy.

Consider the alternative scenario where users bypass IT and go their own way. The user will be faced with a toy box full of things that just don’t fit together: Lego blocks, Meccano, Steel Tec and Minibrix. Before the user can assemble anything useful they have to figure out how to integrate everything by devising all sorts of connectors and converters. Even if mashup platforms provide sophisticated tools to create these connectors and converters, let’s not forget that IT already has industrial strength integration tools and the skills/experience to use them to their full potential – but integration is still hard work. There is a limit to the functionality that can be reasonably used by end-users. This scenario is clearly a sub-optimal approach.

The fact is – business and IT must work together. Each side brings unique skills to the table. You can’t have a situation where end-users try to bypass IT and in turn, IT waits for end-users to fail.


Mashups and SOA: The Last Mile

May 26, 2008

I love great analogies – they allow us to explain complex things in simple terms. I found a real gem today. Unfortunately I can’t find the blog post in which I read it. In the post, mashups were described as SOAs “last mile” (I’m paraphrasing here because I can’t remember the exact quote). I don’t think I’ve read a more succinct description of the relationship between SOA and mashups.

The “last mile” is a telecommunications term used to describe the section of a telecommunications line that runs from your nearest exchange to your home. I think this is a great analogy for mashups and SOA. Here’s why.

The telecommunications system is a complex thing – exchanges, switches, cables, satellites and who knows what else. Thankfully, all of this complexity is hidden from the end user. We use the telephone network every day through a simple ‘user interface’ – the telephone. Most of us don’t know (or even care) how it all works. For the end user, the true value of the telecommunications network is realised through the ‘last mile’ of wire that connects the telephone to the telecommunications network.

SOAs are similarly complex – just like the telecommunications network, there’s plenty going on under the hood but if implemented properly, all of the SOA complexity is hidden from the users. And mashups may be the tangible thing that allows users to realise the full value of the infrastructure and plumbing that is SOA.

Without the telecommunications network, the telephone is a useless gadget. Conversely, without the telephone that sits on your desk, the telecommunications network is a nebulous concept without a practical use.

I believe that mashups need a proper SOA foundation to realise their full potential. I also believe that building a SOA that doesn’t offer tangible benefits that the business can see and touch is a pointless exercise.

PS: If anyone knows the post I’m talking about please comment below or email me.

Business Driven Mashups: Bottom-Up SOA?

May 14, 2008

When developing a service oriented architecture bottom-up is generally seen as bad. Top-down is generally better, and the pragmatists among us argue for a middle-out approach. If you’re not careful, the rising popularity of user-developed, browser-based, graphical mashups will force you down the road of bottom-up SOA design. And that is not a road you want to be on.

In SOA, the same concept means different things to different people so a few definitions:

  • Top down: focuses on analysing the business, in particular where it is and where it wants to go. The SOA is designed to support the business. Close alignment between business and IT.
  • Bottom up: focuses on service-enabling existing IT assets, often without regard to the business drivers for doing so. There is no strategic plan. IT builds a huge services layer in the hope that what they build may be useful to someone, at some point.

It may be oversimplifying it a bit but you could say that top-down is seen as ‘business-driven’ SOA and bottom-up is seen as ‘IT-driven’ SOA.

But that is now changing. Mashups are gaining popularity within the ranks of business power users. Services oriented architectures are starting to be seen by some as mashup platforms. Strictly speaking there’s nothing wrong with that. Mashups are one tangible, visible result of the behind-the-scenes plumbing that is SOA.

Here’s an interesting question though:

If: Mashup adoption is largely business-driven (by end-users).
And: The top-down (i.e. business driven) approach to SOA is the preferred way
Does that mean: that mashup-driven SOA design is a good thing?

The answer (as usual) is: it depends.

On the one hand, SOAs are supposed to support the business. If you develop services that can’t be used by mashups then your SOA is not supporting the business. Mashups provided a good ‘validation tool’ for checking that you’ve designed your services in a way that is useful to the business. Mashups are one potential consumer of SOA services, and will become an increasingly important one.

On the other hand, you can’t have each business unit submitting requests to IT to develop services specifically for their mashup, without considering what is going on in the rest of the business. This will result in an explosion of services developed in isolation, with no reuse potential and no reference to an enterprise-wide strategy. This is bottom-up design. And it’s bad. Just because it’s business-driven bottom-up rather than IT-driven bottom-up, doesn’t make it any better.

Mashups make bazaar-style innovation possible, but the old principles still apply. You need to take a big picture view and create a SOA strategy that aligns with the needs of the entire business.

Mashups and SOA: Learn from the Past (Part 2)

May 13, 2008

In my last post I talked about lessons from the past with respect to business driven mashups. In this post I talk about another thing to keep in mind: the danger of designing solutions from the user interface down.

A typical custom built software application might have a 3 tier structure: user interface, business logic and data access. The idea was that you could design, develop and deploy each tier independently. If you wanted to replace the database server then you could change the data access layer, leaving the other two alone. If you wanted different user interfaces (e.g. Windows application, web-based, mobile device) you just had to write a new user interface layer and reuse the business logic and data access layers.

Sounds great. Except it never worked like that in practice. In many organisations the business logic and data access layers were tightly coupled to the user interface. For example, when web-based applications were all the rage most projects started with a statement like “we need to build a web site to…” From the first day of the project the focus was on the user interface tier ” and the other two tiers were designed accordingly. It didn’t have to be done this way ” there are plenty of design patterns to help you do it properly. It was done for the sake of expediency.

The problem with this approach: it limited reuse. If you wanted to re-use the business logic you wrote for a web application to create a Windows based composite application, you often couldn’t do it without code changes ” and often substantial ones.

What has this got to do with mashups and SOA?

Some see the rising popularity of user developed, graphic based mashups (where the mashing is done at the browser) as a means to getting SOA’s funded. If this is your strategy then here’s a word of warning. If you sell SOA as a mashup platform there will be pressure to cut corners and deliver ‘just enough’ SOA to support mashups. In fact, there will be pressure to deliver just enough SOA to deliver the particular mashup the business wants to create at the time (limiting the potential of creating other mashups later on).

But graphical, browser based mashups are only ONE potential consumer of SOA services. A true SOA should be built with the greatest number of consumers in mind, including BPM, non-graphical mashups, composite applications, application integration and so on.

If you design your SOA specifically as a mashup platform then you need to manage expectations and make it clear that opportunities for reuse may be limited.

Mashups and SOA: Learn from the Past

May 12, 2008

My background is software development. I’ve got “hands on” technical skills – I’m certainly not a Visio/PowerPoint architect. The sheer number of IDE’s, middleware products, database servers, toolkits and various other odds and sods I have installed makes my quad core machine run like a Commodore 64. I’m making a point of this because I’m seriously risking getting an ‘anti technology’ reputation. In my last post I gave my opinion on WOA. This post is about mashups.

Let me say at the outset that I love the idea of mashups. I’ve done a lot of experimenting over the last few months and the sheer ease with which you can assemble a pretty useful mashup is staggering. I’m sure that a typical non-technical end-user would find it as easy, but the time is coming.

IT is a funny thing – the same patterns repeat themselves over and over again. And I’m having a feeling of déjà vu when I look at mashups.

Some (most notably mashup product vendors) would have you believe that you don’t need SOA to get started with mashups. And this is certainly true. But if you look back I’m sure you can remember other business-driven initiatives which promised to empower end users. We ended up with a proliferation of Excel spreadsheets, Access databases, user developed applications, dashboards and reports. And all of these were used to run the business and make decisions. That’s all well and good – if it worked. But in reality it was a real mess – on two fronts, both business and IT:

  • IT wasted enormous amounts of resources on trying to debug and enhance these flaky, undocumented ‘solutions’ when it all got too hard for the original ‘developer’. You couldn’t just get rid of them because they often became critical to the business.
  • The business often got a bit deflated when you said something like “did you know that the ‘customer id’ in the finance system is not the same as the ‘customer id’ in the ‘order management system?” or “you’ve misinterpreted that order status code. What it actually means is…”

Now don’t get me wrong – I’m all for empowering users. But is has to managed.

Enterprise-quality mashups can only be built on top of an enterprise-quality SOA.