An Ounce of Action is Worth a Ton of Theory

At the end of a very nice Chinese meal earlier this week my fortune cookie informed me that “An Ounce of Action is Worth a Ton of Theory”. I was dining with a friend who works for a large Enterprise IT Consultancy and we had been discussing why the practical up take of SOA appeared to be falling behind the massive amount of theory that was being created on the topic…….

I think the following are contributing to the problem :-

Issue 1 :

Some Enterprise Architects are trying to define all of the solutions to all the problems (lots of Theory) without actually putting this in to practice. If I talk to another EA who tells me all about their fantastic SOA, but then goes on to tell me their organisations is yet to deploy (or even model) as single widely used and available service or service based solution…..I think I will go mad.

Issue 2 :

The Enterprise Architects in most companies are doing a pretty poor job of explaining to the business what they can achieve with SOA, what does a business person do with flexibility and agility ? In most cases SOA does not provide ultimate flexibility and agility which means that the business departments who do think of something to do with SOA are often met with the Little Britain phase “COMPUTER SAYS NO”.

So we have a situation where not enough practical experience is being created within the IT department and a business who want innovation and change but don’t have any really good examples or patterns to follow….this all leads to too much theory and not enough action.

One simple chart that I use to explain what could be done with SOA is shown below.



I have translated the EA words of Flexibility and Agility into the simple to understand questions of :-

a) Do you want to create or automate a process and if so how complex is that process (and do you understand it !!!) ?
b) How complex (or pretty) does the user interface need to be ?

By plotting the answers to these questions on the grid we start to get an idea of how simple or hard the process of enabling this for the business is going to be.

As with all things (and SOA is no different) it is best to start small and grow as you gain experience and the great thing with SOA is that most of the skills you learn doing the simple stuff form part of the complex stuff as well. You might choose (and probably will) to use different technologies to enable each of these quadrants, I think this is OK as long as you keep a lid on too much technology proliferation. Each time you actually do something in the real world you will learn what works and does not for you – oh and you might actually add some value to the business ☺

AN OUNCE OF ACTION IS WORTH A TON OF THEORY !!

Flat Packed Applications - aka Composite Apps

I think we all accept that in addition to innovation and flexibility, reuse is a key cornerstone of the business case behind SOA. It is this reuse that means that the same logic is not re-written time and time again enabling organisations to focus on developing innovative new stuff to kill the competition with.

The problem is that getting people to reuse is hard and the key reason behind this is that to reuse something you have to understand it and to understand it you have to take the time to go through a learning curve (you also have to believe that the object is worth reusing).

Now thinking about most of the IT professionals you know in the world who create applications (me included), most of them love to create new stuff. At its heart IT is a creative pursuit – IT professionals are trained to solve problems in new and innovate ways !!!. So some change management is required to enable this change……

So let’s see how they fixed this in the world of furniture making (please stick with me) and see if we can apply these concepts to our own world of IT applications.

50 years ago if you wanted a new piece of furniture you had 2 choices, you either commissioned a bespoke piece (very expensive, but exactly what you wanted) or you purchased from a furniture maker (still expensive and sort of what you wanted). Then Flat Packed Modular furniture was invented….(by Mr Ikea ?). This totally changed the furniture market, it opened it up to people who had not bought new furniture before, it created volumes that enabled manufacturers to cut the costs of furniture AND importantly it did not put the (good) furniture makers out of business, because sometimes you still want that bespoke piece of furniture (to impress your friends or fit into that funny space).

Reflecting this example into the IT world, the bespoke furniture represents bespoke software, the furniture makers are the packaged application vendors and the flat packed furniture makers are SOA composite application platforms.

So how do flat packed furniture makers convince me to buy their furniture…..

Firstly they provide glossy brochures (or websites) that show me (and my wife) what could be achieved with their furniture range…..they don’t show me my lounge or kitchen (or even real kitchens), just examples that catch my interested in purchasing some of their components to put in my own lounge/kitchen.

Secondly (and this step is optional depending of how much I am spending - so key in the software world) they have shops where I can go and touch and feel these pretend rooms to see/feel the quality of the furniture and get design advice from (hopefully) trained staff !!!

Thirdly they (sometimes) provide clear instructions in the flat pack as to how all the different parts fit together and how different components are connected together. Hopefully I get a nice overview picture, step by step instructions to create the final piece of furniture, a list of the tools I need and an estimate of the time required to assemble.

Now some people will never buy flat packed furniture and some people buy it and get someone else to put it together…but you can’t deny that it has had a dramatic impact on the cost of furniture by encouraging us to reuse.

So where are we in the world of SOA and composite applications today ? Well with a few notable exceptions (SAP being one…well I would say that), we are effectively being shown a bunch of screws, connectors and bits of MDF….no big picture, no showroom and definitely no detailed instruction manual.

If we did have these then I believe at least one of the inhibitors to reuse would be removed…..then all we need to do is crack governance, scalability and requirements capture……☺

PUA

SOA is old news, what you need to be talking about is PUA - Pragmatic Unified Architecture.

So what is PUA ?

PUA is all about selecting the most pragmatic architecture style to solve the problem in hand, challenging the silver bullet ideas that one super architecture can solve all the problems that it faces...this doesn't work in real life (not even in Life 2.0).

PUA considers:-

- How long will the solution be used ?
- Does it have any chance to be re-used ?
- How much will designing re-use cost ?
- What non-functional requirements exist (performance, scale, security) ?
- What other components does it need to interact with ?
- Will the process supported change during the life of the solution ?

The answers to these questions will drive you to different styles of architecture, including Monolythic, Components, Event Driven and SOA and I believe you shouldn't just assume SOA is the answer...without asking some of these questions.

Now the other approach is to start using terms like SOA 2.0 or Advanced SOA or second/third/fourth generation SOA to include the above concepts under the umbrella of SOA....but personally I think this is b*******ks, call a spade a spade.

One other reason why you will need a PUA and not just an SOA is all the stuff you already have is already built and most of it didn't know about SOA when it was built...

At the end of the day any good architecture has just one acid test....can you point to a part of the architecture and explain to the business how it helps them achieve their goals (or why you are busy replacing it becasue it doesn't).

Life 2.0 Launched

Have you noticed how adding 2.0 to the end of words suggests that this is a new improved version of the old thing...no more problems just all the benefits....Web 2.0, Enterprise 2.0, SOA 2.0 we even had ERP II a couple of years ago (before it was cooler to call it 2.0).

So I launch here on this blog the concept of Life 2.0 - like the old life only cooler.

In Life 2.0 things will work like they should (in no particular order).....

* Meetings would always have a point
* My children would listen to a word I said
* People would actually use video conferencing instead of dragging people half way round the world
* .....

And blog entries would be nice and short :o)

Don’t under-estimate the importance of the composition platform

Lots of the stuff I read about SOA talks about what a service should be, how it should be charged for and how it should be governed. These are all very important aspects but are for the birds without a decent platform that allows these to be combined into applications.

Following 3 days camping this was brought into sharp focus. The site we were staying on had all the “services” that I have at home. We had empty_bladder_into_sewer, heat_food, covered_sleeping and we had additional services such as get_sun_tan, get_ice_cream and get_wine.

However the composition platform (in this case me) just wasn’t able to invoke these services as easily as it could at home. Trying to get empty_bladder_into_sewer to work with covered_sleeping was very hard to achieve, especially when combined with get_wine :-)

My main point here is that just having all the services was not enough without a composition platform that was able to take account of the non-functional requirements and make them appear to work as one.

SO - Should you believe the hype

Service Orientation (SO) is taking over the world or that is what most of the software and service companies in the world would have you believe. In some circles it is being touted as the answer to all the problems the last big thing created.

So is they hype justified....in a word NO.

SO will not make IT projects any more likely to succeed that ones based on previous architectures, in fact some of the first project will create huge failures - as many people will not understand the rat holes they may be venturing down.

First let's look at some of the things that make an IT project a success and then see how SO will impact on these dimensions.

1) Projects must have a good business case, sponsorship and budget.
2) Projects must have good project governance and a realistic timeline.
3) Projects must have a solid technology base.
4) projects must have capability that understands the problem, the solution and the technology.

SO - Business Case
SO does not change the fundamentals of the business case. Financial returns will remain the same. Where SO might make a difference here is where the re-use factor kicks in. If you are able to re-use components then the cost side of the argument should go down and therefore the ROI will increase. This might move things from "too hard/expensive" to "why not". If your SO guys are not showing any on this type of benefit..get new ones. So the fundamentals don't change but the TCO should be lower.

SO - Project Governance

Again SO does not change the need for good plans and accurate status reporting. SO does create problems for the traditional models as if components re-use is included (which is should be) then the dependencies between workstreams and other organisational units increases. Also the amount of experience in estimating and delivering these projects is quite low. If your SO guys can't show you where they have managed this complexity before...get new ones. So projects could become more complex and harder to manage.

SO - Technology

Hmmmmm....now everyone is claiming to be SO now...and inter-op and standards are at the core of SOA...so you can't go wrong....but you can . Don't assume that standards will be the answer to your problems, standards have the be implemented and sometimes these differ. Don't get me wrong it will work in the end but you will have to work at it. Also each of these "new" products will need to be managed, will have its own upgrade cycle and capability requirement. You could just decide to take your technology from one vendor, but this could be a) expensive and b) limit your flexibility in the future. If your SO guys are telling you not to worry about it...then start worrying and get new ones. So technology has the potential to solve your problems and create them..tread carefully and get your vendors to put skin in the game..

SO - Capability

Overnight everyone in IT is suddenly a SO expert, everything they have been doing for the last 10 years was really SO but they just didn't call it that. This makes recruitment of Systems Integrators and people a minefield. If your SO guys can't show you where they have really done this before...get new ones. Capability will increase in this area but make sure you know what you are buying.


So SO might make things quicker, cheaper and more reliable but only if you apply some good old management to the problem.

How much architecture is enough ?

Design vs. Styling

I listened to a presentation by a car designer from Landrover who defined the difference between car design and car styling.

He defined car design as working from the ground up to make sure that all the "big bits" were in the right place...his premise was that if all of theses are in the right place then the car drives well and looks good.

He defined car styling as what you need to do to a car that has poor design, you have to add bolt on parts and features to make the user believe that it is well designed when it is not....

This made me think about the world of IT where much time is spent on "styling" and not enough time is spent on good "design". It is the role of architecture to try to change this balance.

What makes a good IT Architect

Looking on the The Pragmatic Architect blog the thread on what makes a good architect brought back some interesting memories of the conversations I have had in the past on the subject.

From my experiences the answer is that anyone can be an architect because the term is used in IT to mean almost any job that is carried out….I am sure that developers (who were called programmers) will soon be called code architects.

You therefore need to qualify the term before you can describe what one is in IT. Most of the architects discussed in the Pragmatic Architecture thread are what I would term Solution Architects (in my definition these are the people who are responsible for making sure that the whole solution is effective end-to-end). The architecture types include Enterprise, Application, Functional, Data…..basically the list goes on and on……….

The key to me about a good architect (what ever the specialisation) is that they are able to think of requirements at a conceptual level first and then drive to a solutions – i.e they don’t just churn out the same design over and over again. This is what makes Normal Foster a great architect – would you make a building look like a huge phallus. Along side these architects you need good designers, structural engineers and site managers (we don’t have good words in IT for these yet) and in my opinion most “IT Architects” fall in to this category…..and a good job too as a world full for truly good architects would achieve nothing….

Farmyard SOA

I spend much of my time explaining the benefits of Service Oriented Architecture to people who just want to understand what it can do for them - most rightly don't care about the how.

Recently I was discussing this with a friend who told me about an analogy he has heard about for Business Intelligence users based on the characteristics of animals. I have taken this concept and applied it to SOA.

You have 4 basic animal types
* Sheep
* Cows
* Pigs
* Foxes

Sheep and SOA
Sheep are simple animals and will do simple things over and over again, they want simple tasks made simpler. So SOA can help here by combining process steps together into composite applications which lead the sheep by the nose through the process.

BENEFIT : Therefore it takes less time to train the sheep…but watch out sheep because the next step is to fully automate these simple tasks using Business Process Management (BPM). So BPM is a wolf is sheep’s clothing!!!

Cows and SOA
Cows are quite intelligent, having to learn when to be milked, how to get into the milking machine and can decided when to be milked. SOA can help here by collecting the process steps together and providing clear guidance on the process paths that are available, decisions are required but the choices are limited.

BENEFIT : Again this means less training is required and the cows can learn from the wisdom of the herd……eventually things can get so easy you can employee sheep (which are obviously cheaper than cows)

Pigs and SOA
Pigs are pretty intelligent but left on there own will consume everything that they can eat (access). SOA can help by collecting all the services (both transaction and information) required to carry out a task into one place – think of it like a pig pen. This means that data is only delivered in the context of other information e.g report on credit history for a customer when looking at that customers blocked order instead of running a report showing all credit histories, just in case.

BENEFIT : Once again the training required here is lower, the quality of decisions is high as they are made in context and the system resources are lower as only the information used in collected

Foxes and SOA
Foxes are very smart and will work out how to work round obstacles placed between them and the chickens – imagine chickens as business objectives. SOA can help here by giving them a vehicle to innovate new ways of doing business that enable them catch more chickens. They don’t have to run these new innovation off system and wait for IT the catch up.

BENEFIT : Now we get to the meat of SOA – this ability means you can release all of that innovative power (believe me it is there), which is being suppressed by a slow and cumbersome IT department. You can enter new markets, streamline processes (converting cows into sheep) - like having one massive Excel spreadsheet.

The reality is that most jobs are a mixture of sheep, cow and pig tasks and the beauty of well designed SOA is that it can be brought on stream task by tasks. So all you need to do is work out which animal(s) will benefit the most and start here…….my advice is to look to help the sheep first.

Introduction

I have finally been nagged into starting my own career related blog having used the media as a fun way to communicate with friends.....so thank you Sam (www.sol1.blogspot.com)

For many years I did not consider myself an architect of any kind, I was proud of my practical delivery roots that focused on delivering "real" things. Then with the help of friends I started to realise that actually I was an architect after all.....it was a bit like learning you are gay and coming out of the closet !!!

I am still a practical (or pragmatic) architect and this blog will be used to share my views on the best and worst of the architecture I see.

I currently work for SAP as the Head of their UK Business Technology Architects and before this I worked for glue:, Plaut (UK) and Conoco. The opinions expressed here represent my own views and not those of my current, prior or future employers.

So let the fun begin.......