All posts in May 2010

I heard once that someone got fired for buying SOA. Urban myth? yeah, probably, but if anyone that worked for me “bought” SOA I think I would probably fire them too. Why so emotional you must be thinking – get a life!.  Actually, before going into the SOA question specifically, there are many things packaged up in the IT industry that are “for sale” and many more people are “sold” these packages. Did you ever hear the term “shelfware”?  This term is used to describe a piece of software, often very, very expensive software, that was purchased by an organisation but never deployed into production – in other words it was left “on the shelf”.  This is a pretty bad situation for the customers and suppliers to be in and I have even heard sales people tell excitable stories about how they have closed a big deal that just ended up being shelfware. The excitement comes from the fact that the vendor received all of the money for the software but suffered none of the headaches that can be associated with implementation or deployment.  Deplorable and downright dishonest behaviour but the software business can really be like that.

So, why not buy SOA, it sounds very useful and could revolutionize my company’s business systems.  Well here is the thing, SOA is not something you can actually buy, it’s a principle, I say again, it’s a PRINCIPLE.  just for clarification, A PRINCIPLE is a law or rule that has to be, or usually is to be followed, or can be desirably followed (thank you Wikipedia: http://en.wikipedia.org/wiki/Principle).  Think of it this way, imagine for a moment walking into a surgery saying to a consultant “how much will it cost to make me honest?”, that would be silly right?  You can not buy a principle, you principles are part of you, your personal DNA, a definition of who you are, and on a personal level most people understand this. Businesses have principles too and sadly, in business some people are vulnerable to persuasion – there are always people who will sell you something you desire. It’s funny, when I used the analogy of honesty I thought I would Google to see if anyone is willing to sell me some “honesty” and sure enough, in less than a minute I found this site: http://www.free-hypnosis-mp3-downloads.com/product.php?productid=23.  I am not going to make any judgements about what this site offers for $39.90, if it has value or if it will work, I will leave you to draw your own conclusions – hopefully though can see my point.  Buying (or being convinced to  buy) SOA is the IT systems equivalent of doing just that!.

The problem is, just like the honesty peddlers that exist in the world, there are companies that will “sell” you SOA, that’s right, for a mere $Xm you can buy the SOA principle from a vendor and transform your business systems – and if you want to believe that, go ahead and Google SOA and you will find plenty of willing SOA peddlers.

SOA has had a lot of bad (and good) press, have a look at this entertaining site (http://soafacts.com/), it shows just how anti-SOA some views are, this is the cynical end of SOA and many of the points in here could easily have been written by people who got fired for purchasing SOA.  Actually, the situation is a lot better now than it was five years ago because many more people understand that SOA is just a set of principles and not a product – in other words SOA is something you do and not something you buy.

I am a fan of SOA principles, but don’t much like the prescription of technology standards to deliver these principles upon, so here is my attempt to provide a more positive outlook on SOA facts (in the context of SOA being a set of principles only): –

• Loose coupling for system design is flexible and powerful, this works at all levels of a system.
• SOA principles have nothing to do with technology standards. Unlike some vendors would have you believe, SOA and SOAP for example are not synonymous, it just so happens that SOAP (which is a standard and not a principle), like numerous other standards are useful in building service oriented systems. Service orientation is one of the key principles of SOA.
• SOA is not an all or nothing, pick from it the principles within which your systems are designed
• SOA principles are really targeted at systems designers, architects and software developers and not aimed at business people as some assume. Instead, the systems that are built on SOA principles put the business people back in control of their own systems because they are easier at understand at a high level.
• SOA is only a name, the principles of SOA existed well before SOA was coined as a name.
• SOA was born as a way of describing specific technology standards in a business context. However, SOA has evolved to become a term that describes the principles, with the specific technology standards being disconnected from the principles – at least for those of us that truly understand that one can not purchase SOA

SOA is not the perfect set of principles for every situation, you have to be able to pick and choose which principles you apply.  I would use the analogy of religion – as a general rule religion is a good positive thing for society, it helps with social order, community and leadership but taken to an extreme can lead to radical views and totally unacceptable behaviour by often vulnerable people that follow extreme interpretations of those principles and beliefs. I suppose now I think about it, you could look at buying a global SOA solution from a single vendor as an indoctrination into a cult.

I really feel the need to go into the detail of SOA right now but I am conscious of the fact that I have already written more than enough to bore most readers, so instead if you do want to know more, there is a good explanation of SOA on Wikipedia: http://en.wikipedia.org/wiki/Service-oriented_architecture

Just to sum up – take look at the principles of SOA, if you like the idea of them and can see how to use them to the advantage of yourself or your organisation, adopt the principles and start using them in your designs – you don’t need to go to your boss and get sign-off for a SOA project, your boss won’t even know or care – but when the systems start to deliver real value and results, then your boss will start to care because he will feel compelled to go to his boss to get sign-off for a pay rise and a bonus for you as a reward for the magic you are able to do – just believe! And even if that does not happen – at least you will end up with a flexible and adaptable system.

A subject that popped up a few times at work was Enterprise Architecture and although we seemed to have some expert opinions (yeah right) about it, somehow, no one really had a clue what it was.

In order to find out what EA actually is in practice, I went along to the Enterprise Architecture Summit 2010 organised by Gartner.  The event was held on Monday 17th May 2010 in the London Lancaster Hotel, in – you guessed it – London.  The event was well organised and had some good content.  The Gartner team were professional and very helpful if not a little by-the-book.   I went to this event to find out exactly what EA is because I really did not have a clue.   As it turns out I was not alone, some of the EA vendors that where in the vendor showcase were not exactly sure either,  each seemed to have their own interpretation.  One thing for sure was my initial thoughts on what EA is were pretty incorrect.

Sitting in the various Gartner lead presentations it became very apparent that the focus was much more on “Enterprise Business Architecture” which is another way of saying “strategic planning for IT” and much more appropriately describes EA – in my mind at least.   It covers the areas of business process and data modelling but at a non-detailed (or non technical)  level.  There is a lot of cross-over between what EA seems to be and ITIL V3 around service portfolio and service strategy, at least as far as I could tell from my experience working at Hornbill.  The main objective behind EA appears to be to allow large enterprise businesses to model the “current” and “future” state of their business systems in order to establish the gaps which are then used to define the strategic projects that need to be initiated in order to get from the current to the future state – all in support of the overall business strategy.   In SMB type organisations this normally happens in the head of the visionary driving force, often the CIO or CTO, but when the business gets to a size where a single person simply can not do this for the scale of the business EA steps in.

The EA tools that vendors seem to be offering are essentially repository based planning tools, designed to track versions of artefacts, create or store process and data flow diagrams which are all used to build models of how the business should/could work from a systems and operational process point of view.  I was very pleased to see that open source was on the agenda in part, and Wiki’s were talked about as a tool that is often used with EA teams.  I am a fan of Wiki technologies for documentation projects, and EA really is on the face of it a big, cyclic, configuration managed documentation project.  CMDB’s could be used for this purpose too but in practice a great deal more document management capability would need to be available to make most CMDB solutions a viable EA planning tool.

Despite what generally seems to be thought, EA does not really relate to technology in any direct way at all but it seems to be given to technologists within large organisations, many (but not all) of the people I spoke to their had a technology background but were involved in EA initiatives.   As one of the vendors put it beautifully “People think EA is directly related to technology because of the word Architecture, bit it’s actually all to do with strategic business planning that involves documenting and controlling requirements for operational systems, that often (but may not always) get deployed as technological solutions.

EA is all about business planning and creating/maintaining documentation to define what “is now” and what is “to be”. If you consider what a product manager does for a software product, this is really what Enterprise Architects do for internal business systems.  EA’s define and plan roadmaps, document them but most importantly communicate over and over again what “is now” and what is “to be” in the future.

There was an abstract presentation that was using biology and the development of biological organisms to relate to systems evolution.  It was quite long-winded and I think many people in the room lost it half way through, I was standing because the presentation was full and it was hard to stay there for the hour.  The basic message was, rather than designing a whole system from the top down, why not create an environment where the overall business system evolves by localised innovation. Yeah I thought, SOA to the rescue! A reasonable message but surely there could have been a more efficient way of saying it.

A senior analyst from Gartner in a keynote presentation stated that their recommendation for any organisation undertaking a new EA initiative is to not buy any EA specific tools but instead use Office tools (PowerPoint, Visio and Excel or the like) for their initial planning work – it’s all about requirements gathering, definition, management and communications back to stakeholders – for the first 18 months at least. The vendors at the event loved that statement as you can imagine 🙂  Another good point they made is “the role of an EA is really to facilitate rather than design”,  the design is an operational function, not one that the EA office should be involved with.

Having spent the time to look into this I came out the other side still not being 100% sure that I fully get EA, but I did figure out it had nothing more than the potential to be influential in relation to the execution of IT projects. For me though, EA is off the agenda for now.

If you know better in relation to EA, please do tell…