Thursday, May 27, 2010

Videos from Microsoft Architect Council UK April 2010

Matt Deacon interviewing me - discussion on SOA past and present

My keynote: Convergent Architecture

SOA is business as usual?

I know I have used the term before – SOA IS business as usual; and in this context I have been emphasizing that SOA is simply the way we must do things today. But there are many data points that suggest we have a way to go – that SOA requires considerable change in practices and that it’s by no means easy to figure out all the changes required, let alone implement them.

This week I was talking to a customer who said that they have considerable SOA experience. They have an ESB installed and lots of services. However he said that the services are all point to point, and that there’s almost no standardization or reuse. Now that they have some of the basics sorted they want to gear up and realize their longer term ambitions. And that’s when we started the conversation about reference architecture, policy and so on and so forth.

Another data point occurred this week – Lawrence I were working on ideas for portfolio management for the report in this month’s CBDI Journal. As you do, Lawrence had trawled the web and found various “authorities” on portfolio management and it caused us to have some serious debate because it’s clear the portfolio management world is still locked into “application management”. Shuffling around arbitrary lumps of capability that they happened to build or buy.

Our guidance is that once you accept that “application” is an unfortunate unit of Portfolio Management you are recognizing that the portfolio comprises of a mix of assets that will have higher levels of reuse and inter-dependence. This has a very interesting knock-on effect. Because we have a mix of asset granularity, many portfolio decisions will be taken across the life cycle, not just in the Planning Phase. Of course we will continue to scope out Solutions and Services in the Planning discipline and phases, but we will continue to discover opportunities to create and reuse assets throughout the Analyze, Design and Delivery stages, and our processes need to positively encourage it.

If you have been following our (riveting) series on application modernization over the past few months you will have read about on iterative life cycles for modernization (aka SOA) which leads directly to the conclusion that of course iterative portfolio management is a natural in the SOA world. The idea of a planner or architect making binding decisions on portfolios is over. Today’s portfolios are assembled out of reusable, moving parts which the projects and programs are actively contributing to. They can be broadly scoped out in terms of services, frameworks, platforms and components, but the detailed portfolio management work will get done in the delivery cycle.

For most of us I suspect this is not yet business as usual. Delivery cycles are too focused on . . . delivery! But we need to temper that enthusiasm (business pressure) and place some portfolio responsibility on delivery teams. For SOA to be really effective, that has got to become business as usual.
Lawrence's report on Portfolio Management

Wednesday, May 19, 2010

In-memory madness.

I note SAP is set to make a major announcement this week.

“SAP’s software dispenses with the separate “relational databases” where the data behind such transactions are typically stored, and instead retains the data within the server’s memory. This, says Vishal Sikka, the firm’s chief technologist, not only speeds up existing programs—it also makes them cheaper to run and easier to upgrade, and makes possible real-time monitoring of a firm’s performance.” The Economist May 15th

If you have shares in SAP and haven’t yet sold them, now’s the time.

  1. SAP’s rise to market leadership was because it emphasized business not IT. This is a total reversal.
  2. One time pioneer of SOA, separation of concerns, transparency of technology, SAP has just reversed everything it stood for over the years. In-memory data is putting implementation constraints on business processes and likely to wreck any chance of a consistent information architecture.

Pursuing technology wizardry is simply business madness.