And You Thought Galaxy was Chocolate Bar...but it is a new BPM Tool from SAP

Just had a session at TechEd with the SAP guy who is heading up the development of the GALAXY Process tool that was announced yesterday at TechEd and it was a very interesting and frank session.

Thanks to Marilyn Pratt for sorting it out at the BPX club house.

Things I thought I heard (although I might be wrong) :-

1) Galaxy has a long term roadmap to become a process abstraction layer for SAP – you change the process model and the deployed system changes…cool
2) Initially the focus is "Edge" type Composition for processes outside the core SAP processes, the core maybe exposed later
3) BPMN as a model language – so that both business and IT can understand
4) Tool uses Eclipse so that developers and BPX, work together on the same model – no throwing the model over the wall
5) CAF Guided Procedures will be replaced – but can be used today – Galaxy is still some way off (12 – 18 months)
6) ccBPM will be replaced eventually once the process engine has been proved, but investment in BPEL models will be protected
7) The tool is about modelling and operation of processes. There is still a space for Enterprise modelling tools which model conceptual processes / optimise processes and include other perspectives.
8) Usage of the new rules engine (Yasu) will be key to reducing complexity
9) Many lessons have been learned from tools like CAF and ccBPM, easy usage is key

I think we can expect big things……

One size governance kills SOA Innovation

I have found that it is a great desire of people within IT to try to find a one size fits all approach to innovation management. Unfortunately, as you have to play to the highest common denominator this can mean that innovation gets lots in a mountain of governance paperwork.

Luckily, with the advent of standards enabled enterprise SOA it is possible to keep control AND encourage fast innovation. This is possible by keeping tight control of the service producers (backends) so you know that the atomic business logic is sound and having governance over the various tools used to combine the services into Composite Applications so you know that the final application will fit into your infrastructure.

Once you have this in place you can start to allow projects to use the tools with the appropriate level of governance for the project, not in terms of the budget but in terms of the new service producers and new tools that it uses. If it creates no backend services and uses known tools it should require less governance than a project that delivers a large number of new services and uses a new composition environment.

Let me use yet another house analogy : Think of this in the same way you govern changes to your house. A quick paint job requires little planning and/or control, a major kitchen refit does not require external control but needs carefully planning and budget control, the extension you put on the front needs formal planning consent and if you knock the house down to build 3 smaller houses you might have to go to a planning committee to check all the infrastructure can cope.

Taking these concepts to enterprise SOA means we can relax the controls of some of the projects that are redecorating the existing landscape with composites that open up the system or automate collaboration. We can do this because the atomic backend services ensure that we still update the critical business objects correctly.

So in an enterprise SOA world one size does not fit all.

The Long Tail of Applications

I have just been reading The Long Tail by Chris Anderson and one phrase in the book – Beneath Economic Viability – made me think about how current Enterprise Software requirement, design and development methods work against innovation – which is usually found somewhere in the long tail.

All the methods that I have used for requirements analysis work towards taking out differences in a process and trying to create a logical definition of a process that is modelled once and applied to the mass market.

We have all seen the impact of this on the acceptance of Enterprise Software. Some times we end up with a homogenised, bland solution that doesn’t quite fit everyone but does the job. Over time people work round the system running their “unique” processes in Shadow IT on spreadsheets etc. If we are really unlucky we get a solution that fits one set of users really well (usually those who were most vocal in the design process) and is a mismatch for those rolled in later who get no budget for changes.

Taking a lead from Chris Anderson we need 3 things to make sure that the long tail can be exploited :-

1) Democratise Production – We need to make sure that the tools to create new applications are widely available and easy to consume. YouTube is successful because ANYONE can create a movie now.
2) Democratise Distribution – Once you have created your application it needs to be easy to get it into the market place. This is what Amazon does to make 100,000’s of books available – some of which aren’t printed until you order them.
3) Connect Supply and Demand – With all the content that is available it becomes important to have ways to filter and connected related Applications. This is how iTunes drives recommendations for music you may never have listened to by analysing the community of individuals that it believes are most like you.

With the above in place it is possible to start to move the Line of Economic Viability so that the number of users for an application might only be small but the value it creates for them (and ultimately the organisation) can be large.

The good news is that many of the patterns we see in the commercial world are moving into the software world and the shoots of each of these traits is beginning to be seen…..if you look hard enough.

4 Killer Questions a CIO should ask his people…

1) Do you understand the Organisations Goals and how the IT strategy / Target Architecture helps to enable these ?

2) Do you believe that the IT strategy / Target Architecture will help to enable the Organisations Goals ?

3) Please explain how your activities are helping to achieve the IT strategy / Target Architecture ?

4) What skills do you have to help me achieve the IT strategy / Target Architecture ?

The answers to these 4 questions will help to inform your Communication and Change Management plan - the importance of which is discussed in this interesting blog by Sam Lowe - I will be trying to get along to see him at the Enterprise Architect Open Group Conference in Paris

Governance is NOT the answer

I have just had a major operation on my neck and it now looks like the picture below.


Before the operation I had been having discussion with many people over a number of months about the importance of governance in achieving the benefits of Enterprise SOA.......following the operation I think many people (most of whom sell some kind of Governance Consulting Service) have latched on to Governance not because it is the answer but because it is the easiest thing to consult in without actually having to deliver any working systems (a bit cynical you may think!) – which god forbid might actually solve some real problems and (wait for it) ADD SOME VALUE.

The reasons for this conclusion stems from the drug induced high I was on just after the operation when it occurred to me that I had not just survived the biggest operation of my life because someone "governed" it well (sure it was important that the right people were there and that they had the right tools) – I survived because I had EXPERTS working on me who had TRAINED for YEARS. If you read my blog on SDN about the lack of “real” IT professionals you will start to see what I think is the biggest problem with making SOA work……it is a lack of IT professionals !!!

It is these REAL IT Professionals who have experience, passion and vision that will be able to breath life into your new Enterprise SOA solutions. Nothing of any value EVER happens ANYWHERE if the group of people trying to achieve it don't have passion and vision (experience usually helps but is not a necessity – or we would never achieve anything new). Look at Iraq – the place has about as much Governance as you could throw at a place......but until you have a shared vision of the Target then it will be like nailing jelly to the wall….my advice to the Coalition is spend more time getting the Target vision sorted (it worked in Northern Ireland).

Anyway here is the KILLER question for those of you out there is CIO land…

WHEN YOU LOOK AT YOUR CURRENT TEAM AND YOUR CURRENT “PARTNERS” HOW MANY OF THEM HAVE THE EXPERIENCE, PASSION AND VISION YOU NEED TO ADD VALUE ?

I think you know the answer already :-)

You should promote the ones that do.....or you could commission yet another SOA Governance Study, Define a Charter for your SOA Competency Centre or Implement a Services Repository no-one will ever use.

Enterprise SOA will be achieved through expertise, passion and shared vision.

p.s If you do have a team who has Experience, Passion and Vision – can I have a job ☺

BETA Version or BETTA (BETTER) Version

This is the definition of a BETA version from Wikipedia

"A beta version is the first version released outside the organization or community that develops the software, for the purpose of evaluation or real-world black-box testing."

However thanks to the shop assistant (let's call him Shopii) at the Game Station where I just purchased my Nintendo Wii (for the kids...if you haven't played one you REALLY need to....) I think I have hit upon a better definition.

This is how the conversation went....

Mii - "Do you know what I need to do to get my Wii on-line"

Shopii - "Great news - it is all built in - if you have wireless at home then you are up and running"

Mii - "Cool - this Wii just gets better and better - I had assumed that would need to buy another box"

Shopii - "One word of warning the Browser is a BETA version - which means that it is gonna get BETTA !!!"

Mii - "Cool Dude - Bye (actually I didn't say this bit as I was laughing too much)"

Now I think this is a MUCH better definition of BETA....we are releasing this software to you and it is going to get BETTA...perhaps this is what Microsoft have been doing all the time....we thought BETA meant almost finished....but they meant we need to make it better :-)

Roll on BETTA software....Thanks Shopii

SOA Toddler Syndrome

Been a while since I blogged…life has been busy at work and home.

Anyway both of these have inspired another blog entry on the topic of sharing things.

My children are now 4 and 7 and as you can imagine they argue a lot about sharing toys (actually anything!), and this made me reflect to some of my work experiences trying to get organisations to put in place the required Organisation and Governance structures to encourage people to share IT assets which is at the core of the payback of any SOA/Platform IT strategy.

However you can’t make people share things as I know to my cost with my two children. However depending upon the maturity of the children I have different strategies to encourage sharing.

When they were less than 4 the strategies included :-

Bribery : Offer them some sweets / TV if they share with others
Distraction : Move their attention to something else so the other toy can be used by another child
Time-Out : Remove access to the toy for a short period of time

Now they are over 4 these strategies apply but we can also start to add more subtle strategies like :-

Free Toys : Explaining that if they share their toys they will get access to others toys free of charge
Interesting Games : Explain that if they share more children will want to play more interesting games with them

I am sure I could go on, but the point of this blog is that my very recent experience is that all of these strategies can be applied to change management strategies regarding SOA. However if you have a very immature client the “over 4” strategies may fail as they have not yet learned that simple sharing can bring benefits…before they move to more complex sharing and swapping.

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