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.