LiteBytes from Lustratus Research

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.....

Steve

Reuse still seen as top SOA benefit

I was interested to see, in a recent survey carried out by PMP Research, that the top-scoring benefit expected from SOA adoption was still reuse. The research was documented in the September 2007 issue of Conspectus, and on 1 1-5 scale 'Business process service re-use' scored 4.1 on the benefit list, followed closely by 'provides a more effective integration platform'.

Many SOA advocates talk about SOA being fundamental in terms of building a flexible and adaptable infrastructure while aligning IT and business requirements more closely, resulting in a more agile and effective platform for supporting business needs - so how come reuse still tops the list?

My own view is that reuse is simply the benefit that is the easiest to take in. The others I list above are very powerful, and can promise significantly more overall business value, but they require more than just a technology change. They require changes to working procedures and practices, and much better communications between business and technical communities. So, perhaps, in the eyes of the pragmatic respondents, reuse suggests itself as a reasonably obvious gain which even has a fairly clear and measurable monetary return attached. Reducing redundancy should have a direct correlation on application maintenance costs, for example. And on top of this, it can deliver value from a purely IT point of control (although the value will increase if business departments are involved too).

Steve

Don’t forget productivity when selecting SOA software

When I talk to vendors of SOA software about their offerings, I always focus on the tooling provided with the product – from development tools to deployment tools to life cycle management tools.  Of course vendors will claim that their products are easy to use and highly productive.  Unfortunately, these claims are often not properly challenged as products are being selected for SOA projects based primarily on functionality and ‘enterprise’ attributes.  This is partly because it can be quite hard to establish just how productive the software will be when used outside the demo or pilot comfort zone.  I said unfortunately above because anybody involved with integration projects (SOA or otherwise) will understand the high proportion of effort spent on dealing with the unexpected incompatibilities or consequential issues:  Effort which can be significantly reduced with good tooling.   

Another part of the problem is defining what we mean by easy to use and productive.   In particular, whether a tool is easy to use or productive is closely coupled with who will be using it.  A productive tool for an expert java developer is very different from a productive tool for a business analyst.  Without unfairly blaming our marketing friends, there is a tendency in the industry to assume anything GUI based must be suitable for business analysts and so long as it works in Eclipse, java developers will be happy.  (For instance, I remain to be convinced that the business process execution language, BPEL, is something any business analyst would use - pretty interfaces or not) Needless to say, reality is much more complex and when evaluating the tooling around your preferred product makes sure to match the capabilities against your developer base and not be fooled by the apparently pretty pictures (or lack of them).

Ronan