Separation of Concerns

Jeff Schneider has blogged about how he's noticed that many large organisations are expending a large proportion of their (supposedly) SOA efforts into what is actually work on good old-fashioned separation of concerns.

This is an interesting question - this 'Concern Oriented Architecture' (please Jeff, no more acronyms!) is based around decoupling different pieces of configuration/code from each other so that they can each be defined and managed more easily, but primarily so that they can be shared, reused or assembled more readily - If that is the case, aren't these shared/reusable things actually shared/reusable technical _services_?

They may be, and that is the reason I think why this 'COA' is sometimes presented as being SOA. However, shared or decoupled technical services may be good technical design, but they are not directly related or aligned to any kind of service that a business provides. Jeff and others have blogged about this misdefinition before. One blogger (who shall remain nameless) has even taken to chastising a form of this as 'SOD IT' (Service Oriented Development of IT) !

However, I'm more positive about this approach. Even if it shouldn't be the destination, it doesn't mean it's not a valuable exercise. And what's more, it may well be a valid step on the maturity curve for many organisations toward SOA proper as it may constitute a modernisation of their software infrastructure that enables them to start providing more meaningful services. But (as Jeff says), it does need to be considered separate so that it is not misrepresented. If you are working on an SOA roadmap or transformation exercise, I would recommend ensuring that this is a separate work-stream, and that the business case for doing it holds water independently from the other workstreams. Make sure you ask the hard question for each component or layer, of whether each is really needed or whether it's a technology 'nice-to-have'. It may well be needed, but we all know that just as many value propositions have been blown in the past by over-engineering the technology as have by underengineering it, and sooner or later you will get asked those hard questions, so best have done the analysis before you do.

Technorati Tags: Software Architecture Service-Oriented Service Architecture SOA Enterprise IT EII ESB BPM

Business-IT Alignment: Synchronisation or Aspiration?

Reading Richard Veryard's assertion that IT should be decoupled from the business rather than aligned to it reminded me of a conversation I had recently with an freelance IT Excellence consultant on the topic of business-IT alignment.

He also, like Richard, was of the opinion that the concept of business-IT alignment was unhelpful because it implied synchronisation of IT into the business cycles, which constrained the value IT could bring to the business. Of course he was right about that being negative, and I agree with Richard's arguments about the downsides of that model. Indeed, if you were to make IT a slave to the business cycles, plodding along behind not looking around at the effects of what it was doing, not looking ahead at what it could be doing, then it would only be able to be reactive and tactical. Only thinking about how to turnaround the next request that came its way, unable to innovate, or even think strategically. This is not a good state of affairs, and is actually a bit too close for comfort for some of us to negative characteristics we see today in many organisations. These are the exact constituency for whom improving business-IT alignment was supposed to be an improvement. Have we been aspiring for something that would actually make things worse?

Well, I'm not sure that we have. And the main reason why is that I never use the term 'business-IT alignment' to imply synchronisation. I can see why alignment could be interpreted as implying synchronisation, but that isn't something to be aspired to. On the other hand, improving alignment in objectives, in priorities and language, even in intentions and mindset really are aspirations with real benefit.

And just as important, if not more, is the perception of alignment. That is to say that the lines of business believe that IT are aligned to their businesses and the priorities of the business as a whole, rather than being aligned to their own agendas, their own technology projects, and their technology suppliers. In many organisations, it's only when the lines of business perceive they can get business-focused IT expertise (innovative and/or pragmatic as required) from IT, does IT get invited to the top table.

As I have blogged about before, I do like to look at IT departments as independent IT services businesses. Any independent IT services business needs to operate and innovate asynchronously from the engagements of sales-cycles it has with its customers, but the successful one innovates only in terms of objectives or opportunities its customers have, it thinks in terms of how it can use its own resources to provide value to its clients' businesses, it needs to describe what its value-add is to the businesses of its customers, and it focuses its delivery on success of the overall business change rather than just fulfilling on the technical completion of the task it is in charge of.

We spend too much time in IT discussing semantics (and alignment may indeed not be the right word), so I don't want to reduce the discussion to one of 'which is the _correct_ meaning of the phrase', but there are some big concepts hidden within this that seem worth debating, and that go way beyond a phrase.

Technorati Tags: Enterprise IT IT Management IT Excellence IT Governance Business-IT Alignment

More on the Real Challenges in SOA

I posted around this time last year on this blog about the real issues making and breaking SOA initiatives, and how they are under-served. It was great to see it amplified by James McGovern, but I didn't follow up at the time. Thinking it was about time I did, I have been doing some surfing to see what the current state out there is. Maybe I've been looking in the wrong places but I have to say I havn't come across a great deal that would be of practical assistance to organisations in assessing and planning SOA initiatives.

Of course many on the web (probably best exemplified by the guys at OASIS) have done great work in starting to define the technology-types and architectural patterns involved in SOA, but what about other factors key to organisations realising the benefits that SOA promises?

I'm talking about factors like how SOA affects capabilities and organisational models needed, governance approaches and charging models, mandate & business engagement, migration & transisition methods, workplace infrastructure and methodologies, relationships to current technology portfolio and programme management techniques etc etc etc (this list could go on and on) ?

And in addition to all these 'do-ability' factors, are those to do with how you assess and plan the value of SOA in the first place. For example, how you identify where SOA can add the most value and where it adds the least, because it certainly doesn't add equal value everywhere, and do you really want to be investing your SOA resources in an area which doesn't deliver benefit - maybe where it proves the opposite infact? In my experience getting an answer to this kind of question is necessary to do a decent opportunity assessment, and getting a decent business case put forward.

I don't know about you but it somethimes scares me a little when I think about how, despite the fact that it's now five years since the first time I explicitly used SOA in a large-scale architecture (albeit under the rather ungainly name 'Process-based Service Model'), there still isn't nearly enough practitioner, manager, or business-level content available to people that doesn't have some software-sales spin inherent in it, or isn't about the technology?

I did come across quite an interesting (if very short and dareisay incomplete) post from Carl-Henrik Wolf Lund, which I hadn't come across before. And of course, Brenda Michelson has just convened 'BDA Community Project #1' on a closely related topic (as suggested by MarkG). So there's positive signs that a dialogue might be starting amongst blogging practitioners.

But, if these subjects are key to being able to execute on the concepts that most of the IT industry is holding aloft, why don't you hear about it more than very occasionally in the software vendor SOA hype ? Unfortunately, it is not related to selling their technology. At least not directly related. To be fair to them, I've had conversations with most of the large enterprise application & technology platform vendors on this topic over the past twelve months, and they're all interested in collaborating on these subjects, acknowledging the shortcomings of the view they're able to provide, but are honest that it's just not a competency of theirs, and therefore not going to be part of their core education or marketing strategies.

But many in the SOA crowd (and not just the vendors) need to broaden their sights from viewing SOA, or even Enterprise IT as technology. It may be stating the obvious but Enterprise IT is a business service itself after all, who's toolkit just happens to consist of technology. IT strategy gets a bad rap from many in the operational and delivery technology communities, but you can't solve the thorny SOA execution issues through technology, or through implementations alone. The operating model, governance, skills and culture of the IT department are just as important (actually more), as are IT's relationship with and attitude to the various business units.

Technorati Tags: Service-Oriented Service Architecture SOA SOA Realisation Enterprise IT Architecture Governance

Are Most Enterprise Technology Selection Exercises Flawed?

There is no single best way to select Enterprise technologies or Enterprise application packages. However, having been involved in many (on both sides of the fence, customer-side and vendor-side), it never fails to amaze me that each process I come across seems to either 1) Have been conceived from a blank sheet of paper, from first principles, or 2) Is the rolling out of an old set of templates that someone found on their hard disk which came from a very different context.

I suppose it's indicative of the youth of the IT industry that there doesn’t seem to be perceived or taught guidance on this, and instead the task is often left to people to make up as they go, or is outsourced to 3rd parties who may see the measurement of their success/quality as the amount of documentation produced! Things would be better if there was a dialogue about this, so in that spirit, here's a couple of thoughts/observations of mine to be shot down.

In my experience there really are only three ways I've come across to run a selection exercise:-

First is the traditional Request-For-Information (RFI) followed by Request-For-Proposal (RFP) process.

*Your classic paper-heavy type of affair where each party works through the night in sequence to turn embed every thought or nuance into a series of lengthy documents. You generally dredge the brains of everyone you know, trawl the internet and raid the piles of old trade-magazines that are under your desk, to come up with every product you can buy that might do something similar to some of what you think you might need. And then you start communicating with all vendors via the medium of MS Word whilst refusing to actually talk to anyone.

*Then, typically I find these work on a critical approach I.e. you look for something that is unacceptable about a particular vendor or product based on their RFI answers, and use that as a reason to knock them off the list. Eventually you're left with 2 or 3 to go to RFP with.

*This type of process is unbeatable for auditability, creating a 'whiter-than-white' approach that appears fair to all. However, it is extremely resource and time-inefficient to all sides, and often runs the risk of selecting the vendor who's best at the process (the game?) rather than has the most appropriate product.

Second is the accelerated version of the RFP-centric process, where you go straight into the RFP, with a smaller number of parties, from an independently-researched and validated shortlist.

*This process is great if you know who the contenders are, and you can get away without the paper-trail (most organisations can in my experience). Plus, the increased level of communication possible because of the shorter process and smaller number of participants means the results are more likely to be on target.

*But being able to do this is dependent on really knowing who the serious contenders are in advance. And really knowing does not mean just going for the most famous. This usually means using someone who's got real expertise _and_ experience of similar situations. Please do not just choose the few closest to the top right-hand corner of a Magic Quadrant. Even if it's the right MQ (and who's to say the big G have chunked things up the same way you should), using an MQ alone is a complete lottery. Frankly, it smacks of the IT department wanting the best toys to play with, or worse, wanting the most valuable addition to their resumes.

The third option is to run an interactive process from the start, concentrating on minimising the documentation, and instead scripting the interactions to collaboratively work though the issues, iterating towards a joint-solution that can be tendered against with no misunderstandings.

*This is of course an extension of a joint-design exercise, applied into the selection world. It can deliver the best results where the right selection cannot be reduced down to a feature-function comparison, and a qualitative decision is needed (e.g. on process issues and the user-level experience, rather than technical does have / doesn't have), bringing the business and IT communities together to assess the contenders. It also is the fastest way to get to a selection, thanks to not having the overheads of all that documentation, and instead using the time to do design and education work you’d have to do anyway.

*But, this process leaves little in the way of an audit-trail, and it can only work with a very small number of vendors/products without becoming very cumbersome. So it can only really be considered where there are only a few credible alternatives and the fact that the others are not credible can be clearly articulated (with external assistance normally).

So, there is a quick tour through the three types that I see out there. There are some interesting other thoughts from Tony Byrne here. I'd be interested to hear other people's experiences.

Technorati Tags: Enterprise IT Technology Selection RFP Process Technology Portfolio Management Application Portfolio Management

Mashups in Business - the next big thing?

After far too much Burgundy at the extremely pleasant Les Fontaines earlier in the week, conversation got rather irreverent about some of the less worldly-wise extremes of Web 2.0 - what if (just for fun) you applied the more extreme dogma to some rather inappropriate business scenarios ... mashups in Life Sciences anyone? Should have potential to transform the productivity of the industry to say the least!

Steve Jones has written some of it up in his own inimitable style.

Technorati Tags: SOA Service Orientation Mashup Mashups Business Architecture Architecture Governance