On your Bike: Pattern to Anti Pattern to Pattern

 Posted by at 7:00 am  Anti Patterns, Codification, Enterprise Architecture, Featured, Patterns  Comments Off
Feb 202012
 
biking
Pin It

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. 

Enhanced by Zemanta

Related Posts:

 Tagged with: , , , , , , , , , , , , , , ,

Anti Pattern: Process Fixation

 Posted by at 6:00 am  Anti Patterns, DECISION, Enterprise Architecture, Featured, Management  Comments Off
Jan 312012
 
Pin It

The Process Fixation Anti Pattern

lostinprocess 

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.

Enhanced by Zemanta

Related Posts:

 Tagged with: , , , , , ,

Enterprise Architecture Anti Patterns: Maturity Model Mountaineering

 Posted by at 6:00 am  Anti Patterns, Application Architecture, Codification, DECISION, Enterprise Architecture, Featured, Information Architecture, Patterns  Comments Off
Jan 192012
 
Pin It

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

climber

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.

  Focus Architecture Element
0 No Enterprise Architecture Program No Enterprise Architecture to speak of.  
1 Initial – Informal Enterprise Architecture Process Underway 1.       Processes are ad hoc and localized.  Some Enterprise Architecture processes are defined.  There is no unified architecture process across technologies or business processes.  Success depends on individual efforts. 

2.       Enterprise Architecture processes, documentation, and standards are established by a variety of ad hoc means and are localized or informal.  

3.       Minimal, or implicit linkage to business strategies or business drivers.  

4.       Limited management team awareness or involvement in the architecture process.  

5.       Limited Operating Unit acceptance of the Enterprise Architecture process.  

6.       The latest version of the Operating Unit’s Enterprise Architecture documentation is on the Web.  Little communication exists about the Enterprise Architecture process and possible process improvements 

7.       IT Security considerations are ad hoc and localized.  

8.       No explicit governance of architectural standards.  

9.       Little or no involvement of strategic planning and acquisition personnel in enterprise architecture process.  Little or no adherence to existing Standards Profile		  
2 Enterprise Architecture Process Is Under Development 1.       Basic Enterprise Architecture Process program is documented based on OMB Circular A – 130 and Department of Commerce Enterprise Architecture Guidance.  The architecture process has developed clear roles and responsibilities.  

2.       IT Vision, Principles, Business Linkages, Baseline, and Target Architecture are identified.  Architecture standards exist, but not necessarily linked to Target Architecture.  Technical Reference Model and Standards Profile framework established.   

3.       Explicit linkage to business strategies.  

4.       Management awareness of Architecture effort.  

5.       Responsibilities are assigned and work is underway.  

6.       The DOC and Operating Unit Enterprise Architecture Web Pages are updated periodically and is used to document architecture deliverables. 

7.       IT Security Architecture has defined clear roles and responsibilities.  

8.       Governance of a few architectural standards and some adherence to existing Standards Profile. 

9.       Little or no formal governance of IT Investment and Acquisition Strategy.  Operating Unit demonstrates some adherence to existing Standards Profile.		  
3 Defined Enterprise Architecture Including Detailed Written Procedures and Technical Reference Model 1.       The architecture is well defined and communicated to IT staff and business management with Operating Unit IT responsibilities.  The process is largely followed.  

2.       Gap Analysis and Migration Plan are completed.  Fully developed Technical Reference Model and Standards Profile.  IT goals and methods are identified.  The architecture aligns with the DOC and Federal Enterprise Architectures.  

3.       Enterprise Architecture is integrated with capital planning & investment control and supports e-government.  

4.       Senior-management team aware of and supportive of the enterprise-wide architecture process.  Management actively supports architectural standards.  

5.       Most elements of Operating Unit show acceptance of or are actively participating in the Enterprise Architecture process.  

6.       Architecture documents updated regularly on DOC Enterprise Architecture Web Page.  

7.       IT Security Architecture Standards Profile is fully developed and is integrated with Enterprise Architecture.  

8.       Explicit documented governance of majority IT investments.  

9.       IT acquisition strategy exists and includes compliance measures to IT Enterprise Architecture.  Cost-benefits are considered in identifying projects.		  
4 Managed and Measured Enterprise Architecture Process 1.       Enterprise Architecture process is part of the culture.  Quality metrics associated with the architecture process are captured.  

2.       Enterprise Architecture documentation is updated on a regular cycle to reflect the updated Enterprise Architecture.  Business, Information, Application and Technical Architectures defined by appropriate de-jure and de-facto standards.  The architecture continues alignment with the DOC and Federal Enterprise Architectures.  An automated tool is used to improve the usability of the architecture.  

3.       Capital planning and investment control are adjusted based on the feedback received and lessons learned from updated Enterprise Architecture.  Periodic re-examination of business drivers.  

4.       Senior-management team directly involved in the architecture review process. 

5.       The entire Operating Unit accepts and actively participates in the Enterprise Architecture process.  

6.       Architecture documents are updated regularly, and frequently reviewed for latest architecture developments/standards. 

7.       Performance metrics associated with IT Security Architecture are captured. 

8.       Explicit governance of all IT investments.  Formal processes for managing variances feed back into Enterprise Architecture.  

9.       All planned IT acquisitions and purchases are guided and governed by the Enterprise Architecture.		  
5 Optimizing – Continuous Improvement of Enterprise Architecture Process 1.       Concerted efforts to optimize and continuously improve architecture process.  

2.       A standards and waivers process are used to improve architecture development process improvements.  

3.       Architecture process metrics are used to optimize and drive business linkages.  Business involved in the continuous process improvements of Enterprise Architecture.  

4.       Senior management involvement in optimizing process improvements in Architecture development and governance.  

5.       Feedback on architecture process from all Operating Unit elements is used to drive architecture process improvements.  

6.       Architecture documents are used by every decision maker in the organization for every IT-related business decision.   

7.       Feedback from IT Security Architecture metrics are used to drive architecture process improvements.  

8.       Explicit governance of all IT investments.  A standards and waivers process is used to improve governance-process improvements.  

9.       No unplanned IT investment or acquisition activity.		  



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.

  Business Silos Standardised Technology Optimised Core Business Modularity Dynamic Venturing
IT capability Local IT applications Shared technical platforms Companywide standardised processes or databases Plug and play business process modules Seamless merging with partner’s systems
Business objectives ROI of local business initiatives Reduced IT costs Cost and quality of business operations Speed to market; strategic agility ROI of new business ventures
Key management capability Technology enabled change management Design and update of standards; funding shared services Core enterprise process definition and measurement Management of reusable business processes Create self-contained business components
Who defines applications Local business leaders IT and business unit leaders Senior management and process leaders IT, business and industry leaders IT, business and industry leaders and partners
Key IT governance issues Measuring and communicating value Establishing local / regional / global responsibilities Aligning project priorities with architecture objectives Defining, sourcing and funding business modules Joint venture governance
Strategic implications Local / functional optimisation IT efficiency Business / operational efficiency Strategic agility Organic reconfiguration
 

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.

Enhanced by Zemanta

Related Posts:

 Tagged with: , , , , , , , , , , , , , , , , , , ,

Understanding Architectural Anti Patterns

 Posted by at 6:27 pm  DECISION, Enterprise Architecture, Featured  Comments Off
Dec 272011
 
Pin It

square-peg-round-hole-21

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

Related Posts:

 Tagged with: , , , , , ,

SOA – The architecture with nine lives

 Posted by at 3:04 am  Editors Choice, Integration, SOA  Comments Off
May 222009
 
cat
Pin It

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. Continue reading »

Related Posts:

 Tagged with: , , ,
© 2012 Steve Nimmons Suffusion theme by Sayontan Sinha