Who are your stakeholders?

Okay next up on the project is the stateholder groups. I've split these into three groups

1. Sponsors and Blockers
2. Enablers
3. Informed or Enabled

The first group are those people who if you don't get them properly engaged and deliver what they want they the project will fail, or be seen to have failed, these tend to be the key high-level people who will ultimately judge the success of the solution. They are also the people who can make it much easier or harder for you depending on their expectations of the project.

The second group are the people who will actually help you get things done, this means they will personally help you get things moving and need to be directly involved in the actual work of the project. The project might be changing what they do or they might be the manager or customer of the people who will be changing their practices as a result of your project. They aren't direct blockers from on-high like the previous group but they need to feel actively involved in the project or it will be an outside thing being imposed on them.

The last group are the people who will either be told about what you are doing or will actually be impacted once the solution is live. So they might be the users of the old system you are replacing, the people in the warehouse who will have to cope with the new shelf stacking process or just senior people who like to feel they are in the first group but who in reality have no impact on your programme but you must keep sweet. Needless to say don't tell these senior people that you have lobbed them in this group.

The importance of getting your stakeholder management right is essential to the project. One of the bits from a business SOA perspective that I always stress is getting people's motivations clear about the service and this is an approach I apply to the project.

Why do the sponsors want to be engaged? What will they get out of it? What won't they like?

Repeat for the different groups and you now have a clear picture of the external factors on the project and you can start making plans to ensure that you meet the stakeholder objectives.

Technorati Tags: SOA, Service Architecture

Project Vision - Keep it short

Okay so we've been moving for a whole week here and the most important bit has been knocked down to the two paragraphs and a bullet list that it needs to be. The project vision.

Now reading around some people seem to think that the vision should be a document that includes all the detail around the business case, outline plan and other elements. For me that is the kick-off document and its something that only has a life expectancy of about 3 weeks when everyone is on board and you are into the detail.

The vision for me is something very clear that says

• What we are going to achieve for the business
  
• How we will measure success
• What is important to delivery

Basically I do a "look back" exercise and imagine that the project has finished successfully and what is it that people are saying is brilliant about the project, I also think about what the focus of this is and what are the things we had to overcome.

So this short piece, less than 100 words, basically says to anyone inside or outside the project what we are going to do. It does so in terms of words that describe achievements as in "will deliver the business change and solutions required to drive a 10% increase in sales" and measures "this will be measured based on new transactions through the Gerald system".

So everyone knows on the project what our objectives are and its not long enough for someone to have an excuse to have ignored it, its also concise enough for the person funding it to agree that this is why they are putting up the cash and hold me accountable with clarity for delivering it.

Technorati Tags: SOA, Service Architecture

Starting a new project

Okay so I'm starting off a new programme at work, its not in the "normal" space of most enterprise IT but its going to include business change, IT implementation, a bunch of integration and a load of web tech. Over the course of the next few months I'll run through the various things that I've had to do, why I had to do them and what worked and what didn't. I'll tag the posts "gerald" to give a simple way of tracking them.

Technorati Tags: SOA, Service Architecture

Thinking about service levels

One piece that I've banged on about consistently for the last few years has been the importance of SLAs. SLAs that define not simply things like security and reliability (technical elements) but which also define the business contract and costs. These contracts must always work two ways. The consumer has a contract of things they must do to invoke the capability and have certain expectations of what they want. The service must have a contract of what it commits to do and what are the costs (time, financial, etc) for doing so.

In part this for me is about making pieces like network latency visible to developers and architects but more so making the actual business costs and value visible.

As an example take Paris, that city of surly waiters, stunningly dressed women and the complete decampment of people in August (lots of restaurants and shops are closed in August). Now every tourist wants to "go up the Eiffel tower" but if we look at the contracts here then there are other options that you could take from a "business" perspective.

What do you want to really do? The answer is get a birds eye view of Paris and see all of its wonders laid out before you. Now what are the wonders? The Louvre, Notre Dame, The eiffel tower, arc de triomphe. Now I'd argue that there is a service out there which costs less, in both time and money, which provides a better view, because the Eiffel tower is in it and which therefore represents the best business choice.

So the choice is basically queueing at the Eiffel tower

Or viewing at the Tour Montparnasse


The point here is that its a contract that enables this visibility and choice to the developer/architect/business rather than it being something implicit in the behaviour of a service. If you don't know what the contract is and most importantly what its price is (remembering that time is a cost after all) then you can't make a rational decision. Note here that I'm not talking about UDDI style dynamic discovery and binding I'm talking about making business decisions on a contractual basis.

Another example from Paris (if you haven't been to Paris BTW, stay in the 6th when you do, its "real" Paris in terms of being what you imagine). Now people catch trains and often you want to have a meal or a snack before you travel. Each of these places offers a varying type of contract which broadly covers the following

• Quality of food
• Quality of surroundings
• Speed of service
• Cost

Now lots of train stations have fast food joints, sit down light bite places and even sometimes something where you can get a reasonable meal. The point as a consumer is that my contract is defined by when my train leaves as well as my budget, this impacts what service I will use. If I know about the services before hand however I can plan to arrive at an earlier point if there is something I want to go to.

Now in Paris at Gare de Lyon there is "Le Train Bleu" this is just about the best damned railway restaurant in existence. They have a set of different menus including a "short" (by French standards) one for those who are about to travel.

The point here is that the contract for what could seem to be the same service (food at a railway station) can vary hugely from fast food through to a gourmet experience in an amazingly decorated french restaurant the contract isn't simply about price, or time, or quality, or trust its about a combination of those things and then weighing up which makes the most sense from a business perspective based on the current demands and ambitions of the business.

Exposing network effects to developers and architects is a tiny part of the problem, the real problem is exposing them to the business costs of their decisions and that requires a different degree of formalism and planning.

Once contracts are formalised it becomes possible to automate but the first key is being able to understand the contracts. There is still no WS-SLA or WS-Contract and the current push appears to be away from considering these elements and back to considering only technical aspects of service.

So think about the full contract not just on the immediately obvious this means not following the tourists in wasting 1/2 a day queueing for the Eiffel tower, but going to Montparnasse and having time to take in the cemetery and Jardin de Luxembourg and finishing up at Saint Sulpice having an espresso watching the beautiful people walk by. Now that is quality of service.

Technorati Tags: SOA, Service Architecture

Google Map Rolling on a Mac

I love "silly" demos that combine technologies. Raul Guiu has written a very small app that uses the Mac's motion sensor to navigate around Google Maps. Now my first thought was "nice demo, can't see an application" then I started playing "follow the roads" which was fun for a short period of time. Now however I can think of quite a few bits where adding in motion and GPS could really commoditise certain areas. Take the "Fitness Watch" market, it costs £100-£200 for a watch and the "premium" ones are those with GPS. Now however with my iPhone I already have a GPS but I need to combine the information. The motion sensor could also act as a pedometer as well as indicating on a bike how fast I am going and what sort of lean I got into the corners.

This sort of "personal network" approach (which runs against the "one central device" theory) would give me all of the information I need (and more) and do so over a very limited area (I have them on me, if I don't then they aren't involved).

Its something that I expect we will see more of as things like the iPod/Nike link up are expanded and players like Polar want to get into the act. The key here will be around the short network comms and not burning the battery to get that done.

So yes its just using a Mac to navigate a Map, but it does go to show that not all Mashups have to be of web information. Mashing up personal information in a localised way can be just as, if not more, useful.

Technorati Tags: SOA, Service Architecture

SOA success - value over technology

There have been a bunch of articles around recently on SOA and judging the success but it was this one at HBR that best sums up the business view of what good looks like. Entitled Investing in the IT That Makes a Competitive Difference its all about companies being smart in the application of technology and choosing the areas where it drives differentiation. One of the bits I've gone on about in the book is value classification.

The point is that most companies have a distorted IT investment view with most of the investment going "below the line" and very little going above it. This is madness and is a major reason why businesses get annoyed. The point of the areas below the line is cost rationalisation and even elimination. SaaS is a good example of elimination, you eliminate the data centre and other support costs and switch it into a business metric charge (most often number of users). But you won't differentiate on any business services in this area as if you can do SaaS then so can the competition but it doesn't matter as this isn't where you really compete. Think of your phone system. Does it matter that you use the same mobiles as the competition? Nope. Lots of IT is in the same basket.

we believe that an overabundance of new technologies is not the fundamental driver of the change in dynamics we’ve documented. Instead, our field research suggests that businesses entered a new era of increased competitiveness in the mid-1990s not because they had so many IT innovations to choose from but because some of these new technologies enabled improvements to companies’ operating models and then made it possible to replicate those improvements much more widely.

So its about where technology impacts the operating model, not just about technology. They make a great play however on the importance of standardisation in driving successful change

First, deploy a consistent technology platform. Then separate yourself from the pack by coming up with better ways of working. Finally, use the platform to propagate these business innovations widely and reliably.

In the value classification this means keeping vanilla down the bottom and innovating at the top (where it has the most impact). Its the standardisation around things like SAP that give you the ability to then roll out change more widely, its not simply about having a new shiny technology. So with SAP the Basis platform is below the line, but is a consistent base. You then use Netweaver and new technologies above the line to give you the competitive advantage.

This is the SOA play. Making the business not care about the technology you are using but is asking for two things

1. Standardisation
2. Focus on investment

Standardisation means rationalisation, not just of the IT but most importantly of the business. The business needs to operate in line with the package, not the package in line with the business. Where they need (not want) to differ then you are looking to focus investment at these areas of competitive advantage.

This bit above the line is where you can start playing with Web 2.0 (a Web 2.0 invoicing process... I don't think so) to really understand where it makes an impact. Having it make the impact however is about enabling it to build on those stable foundations and foundations that are able to change in both business and IT in a coordinated manner.

So the conversation has switched from "SOA" and technologies towards a goal of competitive differentiation. It is however the SOA bit that makes the split between standardisation and innovation possible. Without this standardised glue and the business commitment to alignment below the line you are just building on quicksand.

This is a real judge of when SOA is successful, when the business doesn't care about the SOA programmes, when it doesn't care about BPEL/Web Services/REST/etc but what it does care about is that it exists when it becomes an integral part of the companies goal of differentiating itself by providing the platform between the standardised and the innovation and being the mechanism via which those changes can be rolled out across the business.

So if you are doing a service architecture make sure that you do the value classification so you can explain to the business where you want them to invest and where the business and IT need to rationalise and standardise.

Technorati Tags: SOA, Service Architecture

http://www.blogger.com/img/gl.link.gif