Compromising for failure - anti-pattern

Description
This is the anti-pattern where people making compromises to, mainly, business stakeholders in order to get things accepted. Unfortunately this leads to a bloating of the programme and a lack of clarity in its goals.

Causes
The causes for this tend to be political intransigence and gaming. Someone will object in order to get their own pet project on the agenda, a political game will then ensue leading to the person getting their pet project in order to support the overall programme, this will be repeated over and over again leading to multiple pet projects being added to the cost, and timescales, of the overall programme.

Effects
A good example of this sort of anti-pattern is the US Congress where "pork" is regularly attached to bills in order to get certain senators or congressmen to vote in favour. The recent $700bn bailout bill for instance had a huge amount of added pork what this means of course is that things get more expensive than originally budgeted and become more complex to administer (more cost again). It also means in delivery projects that there becomes a lack of focus on the key goals of the programme and instead there becomes a focus on getting the pet projects done well to keep "Person X" happy.
Rapidly the programme descends into a fractured mess as the pet project sponsors care only about those elements and not at all about the over all objectives. Team members realising that success can be achieved via a pet project delivery also focus on those areas as its a more immediate return. The overall clarity of the project is lost and it loses direction and ultimately fails.

Resolution
The first part of the resolution is making sure you have a very high level sponsor who can drive over pet projects. To do this you need a clear, and concise, vision that a senior exec will sign off on and then you need to be clear in what does, and what doesn't, drive you towards that objective. The next bit is getting a backbone. Its very easy to give in and put a pet project in, its harder to stand up and say "no, it doesn't fit here" and the key to that is firstly doing it privately making clear your objections and then secondly doing it to the overall sponsor and finally that sponsor then doing it publicly. Rapidly people will stop trying to force in the pork if they find themselves accountable for trying to push it in.

The final bit is about culture, you need to establish a culture of "do one thing well" that focuses people around simple clear objectives and makes any pork pushing attempt ridiculously visible. The more concise your vision and objectives the harder it is for the pork to be added.

Technorati Tags: SOA, Service Architecture

Boiling the SOAcean - anti-pattern

Description
This is the SOA strategy that tries to much and sets its aspirations far too high. Often it starts as a little point problem before some one suggests that "we could do this as well" before long the SOA strategy is listing solving world hunger and the middle east peace process as secondary objectives that will come from meeting the now agreed two objectives of the project, interstellar space travel and universal harmony.

Causes
There are two basic causes of this problem. Firstly its powerpoint driven aspirational stuff with the people involved knowing they have no real worries about actually having to deliver the stuff they are writing about. Secondly its a belief that there is infinite budget available at least in the long term which is the key part of the this anti-pattern. Planning is for a future in which everything is fixed so you might as well get it down on paper today, this leads people to flights of fancy on trying to conceive of all possible outcomes and how SOA could be used to solve them. The centre to this anti-pattern is the lack of grounding that it has in reality, when combined with aspirational planning this leads to the sort of programme that is doomed to under achieve as it would be impossible to deliver.

Effects
The biggest effects are those of perception, firstly people will think that the programme is over stretching itself (they'd be right) and secondly will be disappointed when it fails to get close to its goals. The lack of focus in the aspirational planning often means that expensive investment is made in infrastructure for potential future requirements. These projects are often cancelled after making that infrastructure investment but not delivering the level of benefits expected for the spend.

Resolution
The key to resolving this problem is grounding it in reality. Push the programme into tight iterations (no more than 3 months) with each iteration delivering quantifiable business benefits this helps to move the focus away from infrastructure and towards the end game and also helps to shift the event horizon of the programme into something more manageable, around a year is ideal. The next bit is to adopt YAGNI as a core principle, infrastructure is procured no more than 1 iteration ahead (i.e. if you are on 1 month cycles then you procure at 2 months) with the first iteration being a selection process.

The final piece is making people get their hands dirty, aspirational planning comes from people who deliver to powerpoint rather than to live, make them responsible for go-lives and it will focus their mind on achievable objectives.

Technorati Tags: SOA, Service Architecture

Pink Floyd meets Frank Sinatra - anti-pattern

Description
This anti-pattern is all about training and learning. Its the "we don't need no education" anti-pattern. It occurs when organisations want to "do everything themselves" and develop in isolation from other efforts and experiences. There can be some reading done but the predominant theme is that it will be done "My Way".

Effect
The effect of this is that the organisation starts creating its own definitions of terms. These are created in a "folksonomy" manner from local opinions rather than taking reference to external sources. Common elements are definitions of "services" that map to things that already exist (see Defensive SOA) rather than looking at a new approach. The other side is that when using technology the company will "learn themselves" how to do the implementation with very little involvement from either the vendor or experienced 3rd parties, the reason for this will be that the company wishes to "learn themselves" how to do SOA, the reality is that they are concerned that external inputs will demonstrate that their current approaches don't work.

The effect of this is that SOA becomes simply another label attached to the companies standard way of working and any changes are purely superficial. SOA rapidly becomes a "best practice we've done for years" and new technology projects fail to exploit the new technology successfully so little, or negative, improvement is seen in productivity.

Causes
The causes of this is an inward facing IT department which sees external companies, including vendors, as competitors rather than collaborators. Sometimes this is combined with a huge arrogance that the company knows best, but mostly its a mistaken belief that in order to remain in control you must do everything yourself. A large part of the issue comes from a fear of new ideas being demonstrated as measurably better than what went before and when tied up with a blame culture this results in a need to protect reputations over open collaboration and improvement.

Resolution
The first part of the resolution is to assess whether you really are that good. If you turn around and find that you are the favoured love child of Google and Amazon and Bill Joy, James Gosling and Donald Knuth are fit only to be junior project managers then carry on, you are right and you are the best. If however you only think that Bill Joy is rather smart, or even employ Bill Joy then remember his mantra at Sun "Most smart people work elsewhere". The second stage is to get rid of the Blame element. You've done an okay job and you want to do a better job. That needs to be seen as a good thing not a bad thing, it needs to be seen as the right behaviour. The next stage is a budgetary one, how will you measure the benefit of external spend and how will you justify it. You need to have clear cases on what you expect external spend to bring and how you will measure its impact. This way you keep in control and use external people to help you improve where you are either weak or where you don't want to waste your time.

Technorati Tags: SOA, Service Architecture

My way or the highway - anti-pattern

Description
This anti-pattern is about delivery processes, given a major goal of SOA is to enable business flexibility its amazing how organisations still insist on having a single delivery process for every type of delivery, or a best two approaches, one for package and one for the rest.

Effect
The effect here is that there is no link between the business drivers and requirements and the type of delivery process employed. No matter whether agility is required or a single compliance driven delivery its always a single process that is applied. This means seeing package projects capturing requirements rather than doing a best-fit analysis, it means seeing agile processes where a vanilla package implementation would be better and it means seeing software development projects doing waterfall because that is what is used on vanilla package implementations.

The end effect is that while the services might map well to the business objectives the delivery process prevents this being realised in a way that matches the way in which the business wants the SOA to be delivered. This gets SOA a reputation as either expensive (e.g. when packages get over customised) or slow (waterfall on a software development package).

Cause
The cause of this tends to be an over reliance on project management in the IT department and a fixed approach. The use of Waterfall across the board is often driven by the finance departments approval processes which mandate that everything must be known and priced before a project can start. Often these fixed processes are part of a broader "quality" initiative where the quality approval people find it easier to have a single process to audit than understanding and coping with different ways of working that actually deliver more quality

Resolution
The resolution is to understand the differing business and technical objectives that business services have and to tailor your process appropriately. This means increasing the ceremony where you have complex contracts and external interactions, it means doing waterfall when you have a vanilla package implementation and are going to change the business to fit and it means having co-located teams when you want true agility and pace of change.

This means convincing the quality people, or convincing the business that the quality people are getting in the way of quality. It also means shooting the sacred cows in the project management organisation and investing in the training and mentoring required. It also involves explaining to finance how different financial approval models make sense in different areas of the business. Its a whole lot of explaining but there is thankfully a whole lot of data out there on how single process approaches tend to destroy IT estates.

Technorati Tags: SOA, Service Architecture

DOA - antipattern

Description
The opposite end to the percolating process anti-pattern this is the one where people assume that data is the centre of the universe.

Effect
With this anti-pattern you see data being driven as the centre of everything, services are all related to data processing and the first set of services being defined are about "key" data objects in the organisation. The actual actions and capabilities aren't captured its all about the data so the Customer service has a series of CRUD methods on it, but nothing that captures how a new customer is really added to the organisation. The impact of this is that it becomes an abstraction above the database but can lead to data silos being created, it can also lead to very inflexible architectures especially where these data services try to include both the "live" and in-process data as well as the post transactional data.

These architectures match nicely to reporting systems but badly to active goal or process oriented areas of the business.

Cause
The cause is pretty simple, its because people have started to do SOA from a Data Oriented perspective and not noticed the difference between the letter S and the letter D.

Resolution
The resolution is pretty simple. Keep the data services as a post transactional base for data, effectively these become the reference data for your systems. Then do a proper mapping of the business services and use these data services as support services and to help communication between different areas of the business, for "live" data keep it local to the service doing the processing and only submit back to the support data services once processing has completed.

Technorati Tags: SOA, Service Architecture

Yes Sir, No Sir, three service views full sir! - Anti-pattern

Description
This is where the time isn't spent to get a clear business service architecture and get the business bought into the approach and where IT doesn't have the confidence, or maybe the ability, to effectively negotiate with the business.
Effect
The effect is that the service definitions are changed on a regular basis, sometimes its just about a data field, sometimes a new capability and occasionally a complete re-writing of the service interfaces. Every meeting that happens results in changes at the interface and service level and the leads to a fracturing of the overall architecture around business silos. Eventually the whole SOA programme is canned because its become too complex to maintain and isn't delivering any benefits.
Cause
The Cause here is IT going it alone and defining a strawman and, unlike IT2B, not having the knowledge or confidence to enforce or structurally modify it. In IT2B the issue is the IT department thinking it knows best, here the issue is the IT department thinking it knows nothing and therefore must always say yes. Often this is driven by a lack of good communicators in IT and through a view from the business of IT as purely an "order taker" rather than a partner.
Resolution
Organisations that have this problem need to drive SOA as a cross-boundary business programme with IT providing support. IT need to invest in highly skilled communicators who can work with the business as partners and help bring together the differing perspectives. At the heart of this issue is one of confidence, communication and ownership, the solution is to make the business the owner and invest in the communication and confidence side of IT.

Technorati Tags: SOA, Service Architecture

ADHD SOA - Anti-pattern

Description

ADHD SOA is where, normally, a group of architects continually shift their mind about what "good" looks like from an SOA perspective.

Effect

This is all about continually "refreshing" the technology stack. On the technical side it means that rather than focusing on getting things into operations and industrialising their approach the architects instead concentrate on the upfront elements, especially the first few weeks of requirements and development and look for ways to continually shave fractions of effort or add additional features.

Both of these result in lots of unneeded work and an increase in the complexity of the IT estate under management, they slow down progression while generating activity.

Cause

The cause tends to be a focus on design and development time optimisations. Unlike the Shiny Nickel pattern which is always about the latest buzz the drive here is always to be different to the last project phrases like "we should try X out" ring around. The most common issue here however is a lack of measures, various different pieces are tried and compared based on personal preference and then combined together on the next project "lets try X with Y but not Z this time". A lot of this comes from vendor product upgrades, after all if you've paid for it then you should use the new features. This isn't driven by industry buzz-words but just pulled along by availability of options and a desire to try new things, often you will end up with bizarre cases where people are pushing using very old technologies along with the latest versions because "we know this worked in 2002" or similar justifications.

The basic cause here is a lack of focus on industrialisation of the delivery process, a lack of measures to demonstrate impact or improvement and a complete disregard for the testing, deployment and operations part of SOA.

Resolution
So how to fix it? Well first off make people really care about operations. Give the architects a target for operations. If the cost of operations doesn't go down then they aren't meeting their goals. Next up get some proper measures on how long it takes to get new people up to speed on a project and how much of the project is automated. Set the architects the task of improving these metrics. The ADHD approach tends to result in an increase in the time it takes to onboard people as its always new to everyone.

Technorati Tags: SOA, Service Architecture

SOA Anti-patterns revisted - Part 1

Back in 2006 I wrote an article, with some help, at InfoQ on SOA Anti-patterns and I thought it was about time to revisit and extend them.

The format again remains the same

Each anti-pattern presented in this article will follow the following format:

• Description - What it is?
• Effect - What you see?
• Cause - What behaviours led to that effect?
• Resolution - What can be done to solve the problem?

First off I'll revisit the old patterns to see if they are still valid.

Antipattern: The Shiny Nickel

Hell yes, people are still lobbing in new technologies without worrying about the consequences so they can get it on their CV.

Antipattern: The Technology Altar

Again its a Hell yes. Some of the REST preaching out there is right out of the technology altar book.

Antipattern: Percolating Process

Again its something I see over and over again. People are still saying things like "Process on top of Services" and I still see people mapping out processes and then calling activities "services" and claiming SOA.

Antipattern: Point to Point Web Services

Its still an anti-pattern but I'll admit that its one that is happening less and less. People are doing ESBs to avoid Point to Point and the REST crowd are claiming the dynamic nature of the URIs combined with DNS.

Antipattern: Splitting Hairs

Again its about splitting process and services, some people are even going further and advising you split further into data/service/process. Its still an anti-pattern and its still being done over and over again.

Antipattern: IT2B

Not really an SOA anti-pattern but an IT organisation pattern and its certainly still a problem.

Antipattern: DIY Transport

Its an anti-pattern but I've not seen someone do this recently. The ones who did this before are now leaping on REST as their transport, I'm still not sure that its any better than the custom XML-RPC approach of before as it still gives a completely unstandardised application interface. But the problem now probably isn't at the transport level. So if you are doing this you are seriously behind the times, its beyond an anti-pattern now and into the category of reasons for commital to an asylum.

Antipattern: Nobody Home

Are people building services without thinking about how they will be used? Oh yes they are. Some people have even talked about not being concerned about the interface design and that "you should at least start somewhere". Well you shouldn't start by making up services based on a set of perceived rather than actual needs.

Antipattern: Too many Cooks in the SOA

Yup still valid.

Antipattern: UBER service

I've not seen this one for 12 months or so, but its still valid.

Antipattern: A Million Services all in a row

Still seeing this, the focus at the edge, build up the volume and "they will come". Muppetry

Antipattern: Architectural Stovepipe

Big strategic views from Enterprise Architecture that result in hard to deliver solutions... almost a best practice in some places it appears. Its still an anti-pattern.

Antipattern: Defensive SOA

Getting worse this one. More and more companies are "already doing SOA" and when you look its the same thing they did before but with a software upgrade.


So to my mind they are all still valid but some of them are less of an issue than 2 years ago. Now what are the new SOA anti-patterns?

Technorati Tags: SOA, Service Architecture