Will mashups mash up your infrastucture?

One of the forecasts in the Lustratus predictions for 2008 Insight, available free of charge from the Lustratus web store, deals with the emergence and adoption of mashups.

At this moment it is unlcear how fast mashups will be adopted, but Lustratus thinks that any serious adoption will place massive strain on enterprise infrastructures, causing the unwary to buckle and collapse.

Mashups seem great. The user is suddenly in a position to create his or her own page layout with all the business applications needed to carry out this user’s activities. A great productivity boost, perhaps, but what are the impacts on the enterprise? Basically, as Lustratus points out, every desktop becomes an application. Instead of an IT department having to worry about 10 or 20 applications, all of a sudden there are 100s or even 1000s. Worse still, while traditional IT-controlled applications are usually controlled fairly rigorously with procedures, policies and management practices, the world of mashups could well be more akin to anarchy.

Fundamental to a productive mashup will be the need to drive the different business services required by the particular user, and therefore services will suddenly become tools used by hundreds in many different ways. All of this activity could create huge traffic increase as well as a generally uncoordinated style of operations, causing major difficulties for the infrastructure software trying to hold everything together.

Well, OK, maybe this is a little negative – but the point is, enterprise architects and management should start considering these issues now. Trying to sort this out when the genie is out of the bottle will be a lot more difficult…..


SOA Communism vs Corporate Capitalism

During a nice break for the Holidays, I got to thinking about SOA and its similarities to communism, and on my return I have been chatting to a number of SOA users and have confirmed my suspicions. SOA is just a communist plot!

Seriously though, there is a real issue here that is starting to affect companies as SOA penetration increases. Once upon a time, IT investment was funded primarily through a central IT budget with all business units having to share the burden, but over the years this became unacceptable to many who wanted a more capitalist view where funds came from the people generating the business and were justified based on returns. So nowadays IT budgets typically fall into two pieces; a central component for the IT ‘infrastructure’ that everyone shares, and project-based funding attached to specific business initiatives.

Then along comes SOA. In its simplest terms, SOA is about two things – packaging functionality in business services, and encouraging the sharing of these services across different business needs. But who owns these services / is responsible for funding them? Are they infrastructure? Well, not really because they are business-driven. So are they funded by a project? But in that case the project is now having to fund something being done ‘for the good of the whole’.

This problem can be seen more clearly if we look forward. Imagine a company where SOA has become a way of life, and all applications are now made up of shared SOA services linked in different ways. Does that mean everything is now infrastructure and should be centrally funded? Then that takes us back to the centralized funding days, losing the link between business need/return and targeted investment. In reality, this introduces the principles of communism, where everyone owns everything, and the problem for companies is that this model stifles business performance and progress. Perhaps one way around the problem is for monitoring and management software to keep pace with the changes, so a clear picture can be built of which business operations drive which services. At least this would provide some more granular level of investment/return linkage.

However, my personal view is the problem will sort itself out – once the initial funding hurdle of SOA has been overcome, project funding to achieve a particular business end will be happy to build the required functionality in ‘SOA mode’ because it will be just as cheap as not doing this, and this will have the convenient by-product of helping other projects. In other words, the kick-back against SOA by projects today is based on being forced to increase investment ‘for the good of others’. If SOA works out right, the future should see projects tomorrow investing less but also seeing others benefit, a much more palatable situation.


Use a hot-house to get better productivity

I was keynoting at the DeutschePost SOA Days technical seminar held in Bonn, Germany last week, and while I was waiting to present I sat through a very informative presentation from a large telecoms company about its efforts with SOA.

However, one point that really caught my attention was the fact that the company has had some success with improving productivity through focusing on 90-day cycles. This extremely challenging timeframe is assisted greatly by the SOA approach used by the company, but a key element is that new projects start off life with a ‘hot-house’ activity.

The idea is to gather the core team of people involved in the project in one room, for however long is required, to spec out the project and select the implementation approach. This looks at the business and IT requirements and implications. What I love is that this ‘hot-house’ is carried out in a special room where there is only local networking available (no internet or email), and it even has mobile phone jammers to block calls. Results appear to have been extremely impressive. The hot-house sets the scene for a rapid development effort. Admittedly not every 90-day cycle completes the project – it can determine that another cycle is needed for additional research for example, but project delivery has definitely speeded up.

As for me, I just want one of those mobile phone jammers – I would love to take one on the train, and turn it on intermittently…..


Integrating the silos: Not only an IT problem

Talking about siloed application is such a cliche in IT infrastructure circles that we can sometimes forget one of the main reasons for siloed applications is siloed organisations.

Furthermore, siloed organisations are there for many good reasons – alternatives exist full of matrices and dotted lines but they do not suit every business, nor are without their own problems.  McKinsey Quaterly recently covered all of this in a report (you need to register for free to read it) which focuses on financial services and highlights the particular business drivers which are forcing greater cross-silo integration:

“Yet many [financial services] institutions find the going tough as clients demand—and increasingly expect—integrated services, including (among other things) advice, the raising of capital, and risk-management solutions.”

There is no simple hierarchical organisation that can deliver this level of integration (and this is also noted).  Therefore, the only solution is to promote and encourage strong formal and informal networks – individuals cooperating across organisational boundaries to address customer requirements. I am sure that IT person reading this who is also thinking about SOA will find all of this very familiar.    And SOA clearly supports these human networks at an application level by enabling easy connectivity between the silos.

In fact, most of the report is about how to map these networks and how to identify the good and prune the bad:

“In our experience, more networking isn’t always better—hence the inability of broad forums to add value by themselves. Indeed, one firm we know raised its productivity 25 percent by eliminating interactions that didn’t add value.”

And clearly there is an IT dimension to this:

“One global investment bank, for example, has put a good deal of money and energy into a knowledge-management system that enables managers from different functions and product groups to access expertise and build on existing knowledge rather than reinventing the wheel.”

While I am being a little unfair in picking on this one example in the paper, this point and a general emphasis on top-down enablement jars a little.  I am sure Web2.0 proponents would feel that this is starting at the wrong end:  The “right” end being make it much easier to create and develop networks by encouraging use of tools like wikis and blogs.  This is the right end because forcing managers into the role of informal network creators is clearly oxymoronic – and counter-productive in my own experience.  Furthermore in most cases, the level of informal networks within firms is low and random and therefore requires something more fundamental than ‘getting to know the team across the corridor’ drinks receptions.

SOA itself also requires the same type of human networks of individuals cooperating to support service reuse and good governance.  Again, the wikis and blogs have an important role to play either in parallel to or embedded within registries and other governance tools – but that is a bigger topic for another occasion.