Patterns becoming Anti Patterns and Anti Patterns becoming Patterns. An illustration using the ‘history of cycles’:

1817 to 1819: the draisine or velocipede

Positives: basic concept established

Negatives: no pedals

Note: Foundational Pattern Established.

1860 Bone Shakers

Positives: Reduced weight, sleeker, more elegant designs, facilitated mass production.

Negatives: Rigid frame and iron banded wheels. Uncomfortable.

Note: Foundational Pattern extended – inclusion of pedals on front wheel

1870’s The Penny Farthing

Positives: Fast, lighter frame (small rear wheel)

Negatives: Dangerous – easy to get thrown over the front wheel, with catastrophic consequences

Notes: A seemingly illogical design variation, but with speed and weight benefits. By modern standards this would undoubtedly be considered an Anti Pattern. Velocipede and Bone Shaker considered Anti Patterns in this design

1886 Coventry Rotary Quadracycle

Positives: Stability, balance, room for two

Negatives: elaborate construction, size

Notes: Arguably a useful derivation of an Anti Pattern (the Penny Farthing)

1880’s and 1890’s – The Safety Bicycle 

Positives: suspension, pneumatic tyres, enabler of female emancipation. Improved comfort and speed, as the drive was transferred to the non-steering rear wheel and allowed for smoother pedalling.

Negatives: Comparably few.

Notes: Gone the Penny Farthing Anti Pattern, return of many features of velocipede and bone shaker patterns.

The basic design pattern of the Safety Bicycle has changed little in over a century.

The Technological Context

Complex Information Systems do not tend towards a ‘Safety Bicycle’ design. There are too many factors such as shifting dynamics, business models, technological advances and trends. Many Patterns become Anti Patterns (although it is not inevitable). In all of the examples above, the wheel (Pattern) is a constant. Patterns become Anti Patterns when a better solution is found, possibly due to new capabilities or insight. Patterns can falsely become Anti Patterns, as illustrated by the design deviation towards the Penny Farthing. The Penny Farthing Anti Pattern was soon recognised, due to serious safety concerns.

In legacy transformation, it is impossible to convert the Penny Farthing into a mountain bike. Penny Farthing conversion Anti Patterns are however regularly attempted in application and infrastructure modernisation.

The Hype Cycle

To continue the metaphor, the Hype Cycle fuels Pattern / Anti Pattern misclassification. The ‘latest and greatest’ might well be the enduring Pattern (the Safety Bicycle). In some cases however it could also be a Penny Farthing, nice to look at, but with few practical or enduring qualities. 

The Process Fixation Anti Pattern

This is a common Anti Pattern, and in the world of Enterprise Architecture is a bedfellow of ‘Framework Abuse’. Certain Enterprise Architects become fixated with process, convincing themselves that meticulous implementation of every conceivable aspect and dimension of the framework they are using (TOGAF ADM or otherwise) is somehow practical and worthwhile. Of course this quickly turns into a waste of time, effort and money. ‘Modelling for Modelling’s sake’ snowballs, with increasingly ingenious reasons as to why the darkest recesses of the architecture need further elaboration. The great fallacy at hand is a belief that, ‘if we follow the process, we cannot go wrong’, ergo ‘if we follow the process to increasing levels of detail’ we can only increase our chances of success. When projects and architectural initiatives fail, adherence to the process is often rewarded with ‘blame amnesty’. Worst still is another fallacious conclusion that the reason for failure was lack of rigour and detail in the application of the process. This fuels more folly in future endeavours.

This Anti Pattern rears its head as closely related variants, such as: ‘the process becomes the deliverable’ or ‘the plan becomes the deliverable’.

The Anti Pattern Codified

Anti Pattern Name [Process Fixation (or sometimes ‘Seduced by the Process’).]

Type: [Process, Management]

Problem: [Process fixation seduces architects into what might be pejoratively referred to as ‘doing the framework’. Execution of the method becomes the deliverable, not the business critical deliverables themselves. They risk becoming‘near-accidental’ by-products.]

Context: [Inexperience (Seduced by the Process), The Defence of ‘I Followed the Process’ – i.e. Protecting one’s Ass(ets).]

Forces: [Regulation, policies and adherence mandates, inability to distinguish between what is essential, what is ‘nice to have’ and what level of detail is required and when. Amnesty for following a good process in the wrong way.]

Resulting Context: [Expensive and bloated architectural models that few understand or use, by-product deliverables, ‘hit and miss’ quality.]

Solution(s): [Use of Pragmatic Frameworks (e.g. PEAF), over-sight of the process by experienced pragmatists, ‘Agile’ mindset.]

This post uses the Anti Pattern template (with some modifications) from c2.com as its structural basis.

The ‘three M’s anti pattern’ – Maturity Model Mountaineering

1.1 Enterprise Architecture Maturity Models

Enterprise Architecture Maturity Models are useful assets, particularly in ‘capability assessments’ as a thinking framework to score and express levels of architectural sophistication within the business. This is important, as it helps surface strengths and weaknesses and drives the capture and recognition of capability gaps. This can be used to direct corporate strategies in training, outsourcing, acquisition, strategic partnering etc.

The anti pattern arises when Enterprise Architects shift focus away from business strategy towards IT led technical challenge.

For reference, the Department of Commerce Maturity Model is outlined in section 1.1.1 and the MIT / Sloan Maturity Model from the ‘Enterprise Architecture as Strategy’ book is outlined in section 1.1.2. There are other Enterprise Architecture Maturity models, including Gartner and Pragmatic Enterprise Architecture Framework models.

1.1.1 DoC ACMM – Department of Commerce Maturity Model

This model originates from the office of the CIO of the US Department of Commerce.

1.1.2 MIT / Sloan Maturity Model (From Enterprise Architecture as Strategy)

This model was produced in 2005 by the MIT Sloan Center for Information Systems Research and IMD.

1.2 The Anti Pattern Codified

Anti Pattern Name [Maturity Model Mountaineering]

Type: [Technical / Architecture]

Problem: [Maturity Models while useful, should never take precedence over business strategy and goals. Architecture that seeks to step through a Maturity Model with no mandate from the business (and no means by which to measure implementation cost and return on investment) is an instance of the ‘three M’s anti pattern.]

Context: [Architecture for architecture’s sake, usually an architectural power-play or ‘architect knows best’ scenario. There are often laudable reasons for this Anti Pattern surfacing, such as attempting to predict future business need. Be cautious, as without business sponsorship and clear delivery of business value, this risks becoming misadventure.]

Forces: [architects like a challenge, architects like pushing the boundaries, maturity models themselves can cause ‘misdirection’.]

Resulting Context: [Broken business / IT alignment, architecture for architecture’s sake, a business might only want to go to base camp – the architect might only be satisfied with the summit.]

Solution(s): [Primacy of business strategy and business goals. Governance processes to prevent architecture projects that deliver no explicit business value. Sometimes implementing this Anti Pattern actually has positive outcomes. It may be that the architect gets lucky and creates a capability that can be exploited by a fortuitously timed event (note: emphasise luck). Ensure that any maturity model does not become an IT led implementation plan or otherwise be misused in contexts for which it was never intended.  

This post uses the Anti Pattern template (with some modifications) from c2.com as its structural basis.

Anti Patterns provide a mechanism to capture and analyse real-world recurring problems. I study Anti Patterns across the Information Systems landscape, taking a series of views including Business, Cultural, Organisational and Technological.

Anti Pattern collection and analysis feeds continuous improvement, an important facet of any approach to Enterprise Architecture. This ensures the approach neutralises or (at worst) dilutes the consequences of Anti Patterns, reinforcing best practice design principles and provision of 21st Century Architectures.

Anti Patterns are usually well-known or easily recognised (but sadly, frequently ignored). Codification of tacit knowledge however ensures that practitioners (at all levels of experience) benefit from a) highlighting the Anti Pattern, b) instilling a culture of Anti Pattern research and c) placement of Anti Patterns ‘front of mind’.

It is important to realise that Anti Patterns (occasionally) become Patterns. Patterns equally need to be periodically reviewed to determine if they are still fit for purpose. This is natural, as understanding of problem spaces and availability of new technologies and approaches means that using dated Patterns becomes inevitable (if they are not being reviewed within reasonable timescales). Patterns have shelf lives, and architects must have the sophistication and discipline to ‘let go’ of favourite techniques, software, applications and hardware if circumstances indicate they are adding to long term cost.

Some consider Service Oriented Architecture to have been proven an Anti Pattern. Others consider that client/server is now a Pattern, having been an Anti Pattern for some time. Because there is often different opinions and finely balanced arguments, the evidence for categorisation of an Anti Pattern (and the context which surrounds that categorisation) must be empirical, not emotional.

In a series of future posts on Anti Patterns I will outline and explore those which must be avoided, and how to mitigate against their intrinsic risks.

There are a number of excellent online Anti Pattern resources, a few to illustrate further are provided below:

1. ArchitectureAsRequirements
2. ArchitectureByImplication
3. AutogeneratedStovepipeAntiPattern
4. ChangesInAugustTen
5. CoverYourAssets
6. DoerAndKnower
7. JumbleAntipattern
8. KillTwoBirdsWithOneStone
9. NotTheAppropriateProtocol
10. PoliticsOrientedArchitecture
11. RequirementsAsArchitecture
12. RollYourOwnDatabase
13. StandingOnTheShouldersOfMidgets
14. StovepipeAntiPattern
15. StovepipeSystem
16. SumoMarriage
17. SwissArmyKnife

Article originally published with the BCS in May 2009

Burton Group’s Anne Thomas Manes recently proclaimed that ‘SOA is dead, long live services’. There was a rapid response from David Chappell at Oracle, spirited pro-SOA cheerleading from Sandy Carter at IBM, as well as excellent rebuttal from Joe McKendrick writing at ZDNet.

What might be regarded simply as ‘headline grabbing’, has stimulated decent renewed discussion and provided an opportunity for introspection and realigning implementation approach. With this in mind Steve Nimmons examines if there is really any life left in service orientated architecture.

I categorically believe that SOA is ‘alive and well’. I think it is suffering from TLA (three letter acronym) ‘burn-out’. The best practices and genuine sensibilities of SOA (although suffering from the tedium of endless repetition) are well founded, pervasive and in many cases practically ubiquitous. As SOA started to become ‘business as usual’ (i.e. a defacto pattern) we sufferers of SOA Fatigue Syndrome (exponents of less talk, more implementation) breathed something of a sigh of relief.

I gave this quote in the latter half of 2007: ‘SOA is disruptive, business and IT alignment potentially difficult and costly and the “the time is at hand” to ensure your major investments are in the hands of professional engineers’.

Was this advice followed and what happened to tarnish SOA’s reputation?

I recall the summer of 2007, looking out across a skyline peppered with the paraphernalia of industrialisation pondering the differences between software and civil engineering. I considered that civil engineers and architects well understood the transformation of customer requirements into functional, safe and cost effective structures.

Experimentation in this domain lived (mostly) in the realm of aesthetics. Tooling, best practices and industry regulation were mature; ‘structural formulae’ and limitations well understood and swathes of truly re-usable assets constantly utilised.

As the multi-million pound buildings sprung up like concrete clones, I considered how eyebrows would be raised if an architect arrived with a blank sheet, vague estimates and limited credentials.

If the concentration turned to the functional minutia (for example workshops to determine the number of desired stairs between floors), it would rapidly be concluded that guidance was being provided by the inexperienced. software engineering and SOA are perhaps more logical in nature, less physically tangible, but there is significant commonality.

Think back, did your suppliers come with reference sites, a defined methodology, established and credible assurance processes; with proven reusable assets (those customisable with limited fuss and head scratching over intellectual property rights)?

Taking the construction paradigm, did you expend valuable time discussing metaphorical stair depths, window frame sizes, concrete and steel mixtures or the width of elevator shafts?

Unless you are a time and cash rich eccentric the answer should be a resounding ‘no’. Why then did ‘the industry’ tolerate a panoply of technological roustabouts, who simply do not ‘walk the walk’ of their ‘alleged’ convictions? What wounds did SOA suffer as a result?

* Hype! IT’s oldest adversary responsible for the demise of many great hopes. As I warn repeatedly, waves tend to hit the beach and leave those on-board wiped-out and washed-up. Silver-bullet / panacea marketing is responsible for many undelivered promises. When it takes ‘the judgement of Solomon’ to separate substance from spin, hype is prime suspect. Hype is also a great attractor of ‘accidental practitioners’, those nomadic creatures whose job titles change in line with the analysts’ annual round of fortune telling.
* SOA was harder than you were told? How many ‘piece of cake’ presentations did you see in ’07/’08? Do you recall the ‘we’ve really been doing this for 20 plus years anyway’ mantra? Wrong! If the funding, sponsorship, commitment and expectations were misaligned you cannot blame the underlying principles of SOA for short falls.
* Wrong people driving it. Not everyone that told you they were a SOA visionary really knew what they were talking about. False prophets lead to false profits. I’m sorry to say the IT industry has more than its share of ‘great pretenders’. This underpinned my 2007 plea to place your SOA implementation in the hands of professional engineers with professional engineering principles
* The ultimate silo. I get exceedingly vitriolic on this topic. This starts with ‘IT and the business’ as if modern enterprises are entwined as the cosmic interplay of ying and yang. No, no and thrice no! This creates or perpetuates a ‘them and us’ culture and created the two ‘ultimate silos of SOA failure’.
* Overly complex tooling. There are absolutely wonderful tools on the market, but RoI is ‘maximised’ when suitable investment is made in training of resources. At the ‘sharp end’ SOA tooling can be tricky and down-right arcane. In the wrong hands I’m afraid it leads to ‘disaster’. Bloated tools created by squabbling vendors trying to differentiate above common standards share some of the blame.

The endless repetition and regurgitation of SOA benefits in itself became tedious. 2009′s ‘hype death’ might well bring significant benefit as some of the ‘accidental practitioners’ head off into cloud, SaaS and other ‘favoured’ domains for 2009.

But still I say ‘long-live business component encapsulation, abstraction, orchestration and choreography, re-use, composite applications, decoupling, asynchronous transactions, governance, interface contracts and canonical data’. If SOA needs a ‘new name’ then so be it, but let’s not artificially separate ‘baby from bath water’ in an act of sacrificial convenience. Leave some milk out for SOA, that silky architectural wonder with numerous lives and numerous names.