Can Enterprise Architects ever be “stratactical”?

I was introduced today to yet another new term – “stratactical”, in a rather good ComputerWorld article.

The definition is given as follows:

Stratactical is the word the enterprise architects at San Mateo, Calif.-based Con-way Inc. created to describe their work. “We use it all the time,” says Maja Tibbling, lead enterprise architect at the freight transportation and logistics company. “Our team takes into account both the strategic and the tactical.

I confess I found the idea quite attractive – to reinforce the importance of building IT systems and related business and IT processes and procedures that take into account strategic goals while at the same time satisfying immediate needs. Indeed, I have long been an advocate of ‘incremental strategies’ where long-term vision and goals are set, and then day-to-day activities and tactical projects are put in place that at least do not exclude the longer term picture, and hopefully go another step in the desired direction.

However, I am not sure I can extend this to the idea of having individual architects who are charged with being ‘stratactical’. This may sound like heresy, and I can imagine my good friends at IASA, the spiritual home of enterprise architects, having a fit over my assertion, but let me explain.

I absolutely think that architects can have the wherewithall to understand tactical and strategic issues. The question is whether it is practical to charge an architect with both duties. My own view is that the pressures brought to bear through tactical, often urgent, time-conscious, possibly localised projects is overpowering, and the danger is that no matter how well-meaning an architect might be, the need to design a solution fast is hard to withstand. Almost inevitably, short-term decisions will be taken that may actually go counter to the longer-term strategy.

Although confrontational, I prefer a split approach where there is a policing authority driven by architects charged with achieving the long-term benefits of the selected ‘grand design’ as well as other architects working to help tactical teams build solutions. Yes, it is irritating and time-consuming when the corporate architects raise an issue over some short-term solution, and indeed the agreed decision might be to ignore the long-term issues and go for the quick gain, but at least it will be a conscious decision achieved through some management-driven procedure. The alternative is to ask architects to make these sorts of calls in their own heads, with no ‘protection’ as can be afforded through the more formal approach – I think this is unfair on the poor architect.

So,my vote is for an architectural community that is ‘stratactical’, but a separate, management-backed body of architects charged with keeping the vision alive to balance others who are trying to address the demands of the tactical project and its drivers.


Why does SOA keep forgetting about data?

Every now and then, we all hit that point when we want to stop everything and say enough is enough.

I guess I have just reached that point. I spend my time working with buyers, sellers and implementers of SOA, and just about every conversation is about applications. There is a myriad of tools and platforms that are focused on being able to turn existing code assets into SOA services, building composite service and constructing orchestrated flows…..but everything is discussed from the point of view of the application.

I guess what frustrates me is that when I talk to people about what they want their services to do, particularly when you get to composite services where functions are linked together, the answer is usually two-fold – I need to run the following applications or components, and I need to access the following data. When building an orchestration flow, for example, it is often very useful to be able to interrogate data to help determine the appropriate next step in the flow.

It seems to me that most SOA products don;t really consider this. At most, they allow database calls during flows, but this is hardly in the spirit of SOA. Surely, these calls should be allowed to any data source in the SOA network, whatever the data architecture or format. This would fit with the SOA theme about offering everything under a standard interface.

Come on guys – I know data might seem boring, but it is just as important as the applications themselves.


Is Open Source the next enterprise software giant?

Guy Nirpaz commented on my post about Oracle’s potential BEA acquisition…

…stating that he believed that OSS should be on my list of the big 4 (IBM, Oracle, SAP and Microsoft) if you consider middleware in particular.  I would agree that middleware is certainly an area which OSS is playing an increasingly important role.

However, OSS does not necessarily represent the increase in choice you might expect as in many cases the big players either dominate or can dominate if they choose to (the investment in OSS by big players is excellently covered in a Harvard Business School working paper referred to here).  In those cases, there is a potential risk that the OSS becomes positioned as the entry level offering with the pay-per-license version containing the features required for serious use or used to reduce the level of choice available by putting pressure on smaller vendors.

For smaller backers of middleware OSS, historically it has proven difficult to create a sustainable and scalable business model.  However, I believe that is a market maturity issue rather than an underlying weakness in OSS approach.  Already, we are seeing the emergence of some interesting business strategies which seem capable of sustaining a growing business.  If one or more of these work out, then OSS enterprise middleware players may emerge (or existing vendors successfully transition to Open Source business) which will challenge the hegemony of the big 4.


Oracle moves to buy BEA: The end of the J2EE era?

Oracle has finally done what so many rumours have pointed to for at least a few years:

made an offer to buy BEA.  I am sure that there will be much comment on the challenges of dealing with the total overlap between BEA’s core product – the WebLogic applications server – and Oracle’s application server (both in the top three by most measures of market size).  The move should also take the wind out of speculation that Oracle will make a spoiler bid for Business Objects.

The writing off of BEA as a business by some has been totally over-stated.  However, I think if this bid is successful it does marks the end of the J2EE era.  Not that I am suggesting that J2EE application servers are going to go away of course.  Rather, the world has moved on from what created that market in the late nineties.  At one end of the spectrum, the focus has moved back towards technology independent architectures with SOA (just as CORBA attempted to do in the pre-J2EE days – all be it by creating another set of technology).  At the other end, lighter weight approaches such as Spring have superceded the heavier and more complex EJB model (which to be fair has also moved with the times but probably too late).

It is also worth noting that the disappearance of the large enterprise focused ISVs continues – in one week we appear to be losing another two.  It is beginning to look like that the enterprise software market is heading for a strongly polarised world made up of a big-four (MS, Oracle, IBM and SAP) with a huge gap to the next division.


Trouble with evaluating SOA ROI

I was trying to think how to get another TLA in that title, since I think you get a prize for having three three-letter-acronyms in a row.

However, the topic is definitely getting a lot of attention as companies try to decide whether SOA is worth the effort. The problem is, SOA benefits span a wide range, and are often difficult to assess. And yet, as John Soat notes in Information Week, real customers are showing major gains with SOA.

My take is that it is important to sort benefits into a spectrum of tangibleness (if such a word exists). So, reducing redundancy should have an actual dollar value reduction in maintenance costs – a tangible number. Delivering the agility to deal with new regulations more quickly is difficult to estimate in dollar terms, but could even be a survival issue. Seems to me the key is to find a way to include the full range of elements in any justification or evaluation.

Perhaps one way to add a dollar value benefit on some of the intangible benefits is to ask the executive in charge of the area most affected how much they would be prepared to pay to solve the issue. So, it might be interesting to ask the CFO how much he would invest to ensure the company could comply with new regulations within the assigned deadlines. This, then, becomes a tangible number that can be plugged into the case.


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


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


SOA, governance and the Trough of Disillusionment™

All shiny new things in IT go through a cycle of boom and bust before becoming an established and useful part of the enterprise IT world.

This cycle is as much about the need for marketing departments and the press to have something new to write about as it is about ‘real’ issues.  The pattern is so well established that Gartner even has graphic to capture where technologies are in what they call the hype cycle – the lowest point before technologies become generally understood and used is called the trough of disillusionment.

Service Oriented Architecture is no exception and Brenda Michelson of Elemental Links even celebrates the possible arrival of SOA at the trough of disillusionment as a good sign!  Moreover, I suspect that with SOA the trough may be worse than with most because it is more fundamental to the enterprise than ‘point’ technologies and attempts to address the fundamental issues of alignment with business strategic and IT agility.

I contrast SOA with point technologies because SOA is actually about changing the way IT solutions are created, deployed and maintained – not providing a single (however big) solution to a single (however big) business problem.  In essence, it is about enterprise architecture (and architects) and how this fits into the whole business.  This means that with SOA there should be no such thing as a stand alone project.  A stand alone project is inherently suboptimal as it removes the opportunity to reuse existing services and to expose further services.   It may take organisations many years to get there but this is the final destination.  This means that the organisational impacts of SOA (both human and technological) are in the long run the most important aspect of SOA.

What has obfuscated this point to a degree is that most discussions around these issues are gathered into the term governance.  Unfortunately, using the term governance has put off many of the people who should be interested – perhaps governance suggests discussions on how to organise committees!   Furthermore, the term has to a degree been appropriated by vendors with products which assist in the technological aspects of governance.  And finally, there isn’t a single clean solution to governance as it is inherently tied into the way each organisation does its business which makes it hard for the press to get to grips with it.

All of which doesn’t take away the fact that governance is where SOA success will happen or not.  This of course does not mean that we now need a big-bang SOA Governance investment.  To quote Fill Bowen from IBM speaking at a presentation/discussion on governance hosted by the SOA Consortium at its European event back in June:

“your SOA governance [should be] based on the level of SOA effort. So putting a
Cadillac SOA governance system in place when your SOA effort is targeted at just
trying to walk seems to be a little bit of overkill.”


The Year of ESB-ability

Recently, I wrote about the ESB (enterprise service bus) maturing at a basic functionality level, and how the focus was swinging around to the ‘-abilities’ such as scalability, availability, usability, manageability, etc.

There is also a free paper on this subject, available from the Lustratus web store, available here.

I noticed my post generated a number of responses from various people. These were all on a theme which I found quite amusing. The accusation was that ESBs are NOT mature – but the posts then went on to demonstrate exactly what I was saying. Take, for example, the illustrious Jame McGovern’s excellent blog on Enterprise Architecture. In his wrap-up of links for 2007-08-05. James discusses my post :

Another industry analyst gets it twisted by stating: the ESB concept has matured, the functionality checklists are of less value – everyone ticks most of the boxes which holds true if you decide to ignore enterprise security considerations.

David failed to consider more carefully what I said about basic ESB functionality. My point was that now that ESBs in general can support the basic functions of an ESB – pass messages from component to component with mediation services available in-flight for enrichment etc, support key standards such as web services etc – that attention is turning to the functionality surrounding these basic operations. That is, the characteristics and all those functions to actually make the thing usable in a production environment. If David had gone on to read the Lustratus paper I referenced, he would have seen that security was classified as an honourary ‘ability’ and is indeed one of the types of functions that people are now demanding.

Other posters fell into the same trap. So, I think we are actually all in riotous agreement. I may not agree with the next bit of David’s post about the need to support such standards as SPML, XACML and WS-Federation, but that is largely because I can never keep up with the stream of new standards, and as most people know who read this blog regularly, I have a highly cynical view to many standards – particularly to WS ones outside of the obvious and more mature ones, as I outlined in my post on WS-Madness.


SOA for the scientific community – a practical example

I was intrigued to discover a discussion paper from the University of Southampton in the UK about how SOA is helping the scientific community.

The paper, entitled ‘A Collaborative Orthopaedic Research Environment’, describes how SOA has been used to enable a Virtual Research Environment for orthopaedic researchers to collaborate in the design, analysis and dissemination of experiments.

What I found most interesting were the reasons for using SOA as the base architecture for this environment. The key objective, based on input from the specialists who will use the system, was to provide an easy way to share scientific data and results from collaborative research. However, it was deemed essential that the system could also evolve based on the changing requirements of the user community. One example of change that the paper gives is that of knowing which of a wide range of protocols will be followed for a particular clinical trial. Not only do these vary considerably, but it appears they are also susceptible to changes in regulations.

The solution decided to utilize a coarse level of services, essentially using just four – to manage the trial-related data, analyse it, submit and disseminate related research articles and support discussion forums. However, through the reliance on SOA, these services are flexible and extensible, making it much easier to address the changing needs of this particular scientific discipline. In addition, the services are reusable, and some could therefore be usable for other scientific areas.

It’s good to see SOA being used to effectively address clear user needs in this way.