The Architecture For This Project Is Out Of Scope

not my monkey

It is fair to say that the project in question has not started well. A lengthy incubation period executed in isolation from business and delivery partners has seen resources consumed in exchange for very little demonstrable progress, and high-level commitment waning. Faced with challenges like these, project managers will often retreat into their defensive belief systems — the heavily-dogmatic linear methodologies. Under such circumstances, the project manager looked me in the eye and uttered the incredible words:

  • “The architecture for this project is out of scope for this project.”

This statement dumbfounded me, and made me think. Another literal expression had been made of the natural tensions between enterprise architects (and their broad-context thinking and striving for change-friendly capability delivery1) and project managers (and their project-constrained and limited-context viewpoint and striving to achieve traditionally-measured project success). Variously, while i am:

  • accepting that enterprise architecture does not have a strong track record in the successful application of its own heavyweight frameworks
  • holding strong personal convictions that well-executed P3M (Portfolio, Programme, and Project Management2) has transformative potential for good
  • noting signs that enterprise architecture and P3M practices can deliver better business outcomes working together harmoniously3

…i’m too often seeing struggling projects “remedied” through the application of portfolio-grade heavy management and governance techniques, with the primary effects being:

  • greater focus on time and budget, at the sacrifice of scope and benefit
  • more expensive (in terms of both effort, money, and time) project contols
  • blossoming of the infamous opportunities register

For this to change, the culture of projects, and the culture of enterprise architecture, needs to change, meld, and align — a new conversation is needed, needed to lift every project’s context for decision-making up to at least the portfolio level.

It was much later before i established the link with this item doing the rounds on Twitter:

  • “Not my problem” in Polish is “nie moj cyrk, nie moje malpy.” Literally “not my circus, not my monkey.”4

There it is, the crux of the execution-time tension: “not my circus, not my monkey“.

As we step down through the layers of P3M we find portfolios (selected circuses and selected monkeys), programmes (small numbers of circuses, small numbers of monkeys), and projects (one circus and some of its monkeys).

With its enduring concern for the broader context, enterprise architecture is concerned with the enterprise: with all the circuses, and with all the monkeys.

  1. Enterprise Architecture in 140 Characters, Brenda Michelson, Elemental Links,
  2. The Project, Programme and Portfolio Management InfoKit from JISC provides a good overview of P3M.
  3. Bittler, R.S. (2012) Best Practices for EA and PPM Integration Toward Improved Business Outcomes, Gartner Research, Article ID #G00237525, gives a pragmatic and actionable set of best-practice suggestions for aligning enterprise architecture and P3M teams and initiatives.
  4. @howardtaylor on Twitter at


Ideal Circumstances for EA Frameworks

Ideal Circumstances for EA Frameworks

Significant touchstones, at least for some people, some of the time, the series of hype cycle devices published annually by Gartner inform and guide industry behaviours, lead and shape the formulation of strategy.

Three features of the current enterprise architecture hype cycle1 are noteworthy, or thought-provoking, or self-evident:

  1. Whole-of-Government enterprise architecture has been cancelled due to lack of interest and because it is unlikely to deliver transformational benefit… except under ideal circumstances.
  2. Enterprise Architecture Frameworks are on notice, because they’re implemented as a whole insufficiently often to make solid ground, they’re probably a decade away from delivering benefit, and too many enterprise architecture practitioners are distracted by them.
  3. Enterprise Architecture as a discipline “…proactively and holistically leading enterprise responses to disruptive forces by identifying and analysing the execution of change toward desired business vision and outcomes” is moving into the plateau of productivity, and the discipline of enterprise architecture will deliver transformational benefit within the next few years.

Tying these features together and thinking about what they mean for my own enterprise architecture practice generates the following simple good-vs-less-good system:

  • Old School: heavy-framework approaches tend to be neverending documentation exercises capable of producing enormous amounts of exactingly-beautiful and perfectly-irrelevant families of well-organised zero-benefit enterprise architecture artefacts.
  • Change-Friendly: the ultimate outcome of enterprise architecture is change-friendly capability delivery3

…and some unanswered questions:

  • Ideal Conditions: what are the ideal conditions under which enterprise architecture (as a discipline) and enterprise architecture frameworks (as a belief system) and whole-of-entity enterprise architecture (where “entity” might be a division, an enterprise, a government, or a global corporation) may thrive and deliver the transformational benefit they promise?
  • Measuring Benefit: particularly vexed and repeated plaintiffly everywhere, the question of how we as a community of enterprise architecture professionals measure (and communicate well) the benefit delivered by the enterprise architecture discipline.

Whether emergent, pace-layered, pragmatic, lean, agile, or just-enough — by any name, involving enterprise architecture in change initiatives, in strategy formation, in policy review, in service design, in everything, usually leads to improved outcomes.  This happens through a focus on the discipline, values, and core principles of enterprise architecture, rather than through the naked and contextless application of the heavy frameworks.

With the enterprise architecture discipline thriving, and in some areas undergoing a resurgence, we might yet as a community of practice be able to create for ourselves those very ideal conditions under which the frameworks, too, might thrive… what are the ideal conditions for enterprise architecture to succeed?

  1. Burton, B. & Allega, P. (2012) Hype Cycle for Enterprise Architecture, 2012, Gartner Research, Article ID #G00234608
  2. Gall, N. (2012) Gartner’s 2011 Global Enterprise Architecture Survey: EA Frameworks Are Still Homemade and Hybrid, Gartner Research, Article ID #G00226400
  3. Enterprise Architecture in 140 Characters, Brenda Michelson, Elemental Links,

Heal the Eternal Disconnect Between Project Managers and Enterprise Architects!

flexible fire loopTypical exchanges between project managers and enterprise architects have historically, anecdotally, and sterotypically been predictable, unconstructive, and unsatisfactory affairs that juggle and irritate tensions across dimensions such as:

  • enterprise context vs project scope
  • change-friendly capability delivery2 vs project delivery
  • methodological and framework differences
  • open/collaborative vs closed/secret

The nature of these exchanges has led to the creation of an eternal-looking disconnect between project managers and enterprise architects.  Flummoxed recently by a representative exchange that ran like this:

  • EA: “those requirements still need a lot of work, not least because they don’t provide the necessary coverage, and because there are mistakes throughout them”
  • PM: “no, we don’t have time to make them better, because we’ll then be behind schedule”
  • EA: “…but they’re wrong, inadequate, and embarrassing, and intended for publication externally to vendors!”
  • PM: “they were circulated to a reference group before you saw them, so, under the project charter, we’re not allowed to change them now anyway”
  • EA: “…but they’re wrong, inadequate, and embarrassing”
  • PM: “it is what it is, so just eat it! you enterprise architects are all the same, you’re all annoying, and not one of you understands what a successful project is, or how important following the correct methodology and controlling scope is to ensuring success”

…i have become certain the fundamental issue here is context.

In terms of the Zachman Framework3, the audience perspectives illustrate the context neatly, ranging from high-level whole-enterprise-and-beyond context:

  • executive = business context planners

…down to constrained appropriately-defined task-scoped context:

  • implementers = business component implementers

Traditional concerns of the project manager are all about landing something, landing anything approved by a steering group, landing an awkward three-legged contraption on the fluid trampoline of a go-live date. Traditional concerns of the enterprise architect are all about understanding how any change is incorporated into the functioning enterprise, and how to ensure that change is sustainable, able to be integrated within the business and technology bedrock of the enterprise, and consists of repeatable patterns and reusable artefacts for good, generating business value beyond the immediate at-hand implementation scenario.

The three legs of the awkward contraption are, essentially: effort, money, and time… but, just as Todd Biske outlined recently and eloquently1, the project-delivery obsession with being on-time and on-budget readily sacrifices scope, scope, the reason for and the justification of the project being commissioned in the first place.

The disconnect spans a greater distance than the relationship between project managers and enterprise architects.  The disconnect is cultural, and relies upon much better project execution, much better portfolio and programme management, and much better procurement processes.  It’s a core responsibility of the enterprise architecture profession to ensure these activities work together well, create business value, and facilitate change-friendly capability delivery.

Ultimately, the disconnect can be healed only by participants with broad-context viewpoints and strong commitment to ensure that change delivers sustainable business value. In this ecosystem, the only suitable relationship leader is enterprise architecture, enterprise architecture doing its job as advertised, and doing it well.





  1. Think Enterprise First, Todd Biske:
  2. Enterprise Architecture in 140 Characters, Brenda Michelson, Elemental Links,
  3. About The Zachman Framework at Zachman International:

Define Cloud Computing and Abolish Cloud Confusion!


The Understanding Problem

While presenting a keynote address to an audience of information-technology people from the higher-education sector, a senior representative of a super-vendor smiled handsomely and said:

The cloud means different things to different people.

That is a very unhelpful statement.  Perfectly-clear criteria define what cloud computing is, and therefore what it is not.  There is still widespread marketplace confusion about the benefits, patterns, and use-cases of cloud computing.  This confusion is caused partly by people lacking or losing reference to the fundamental definition of what cloud computing is.

The Elastic Definition

In 2010, the Burton Group defined cloud computing as:

The set of disciplines, technologies, and business models used to deliver IT capabilities (software, platforms, hardware) as an on-demand, scalable, elastic service.

This definition is as good as any that i’ve seen, and it is accompanied by a set of five essential characteristics, features of a service that must be present if the service is able to be defined as cloud computing:

  • it uses shared infrastructure
  • it provides on-demand self-service
  • it is elastic and scalable.
  • it is priced by consumption.
  • it is dynamic and virtualised.

The NIST definition published in 2011 also includes essentially the same set of five essential characteristics that must be present for a service to be described as cloud computing:

  • on-demand self-service
  • broad network access
  • resource pooling
  • rapid elasticity
  • measured service

Both NIST and Burton go on to describe service models (e.g., IaaS, PaaS, SaaS) and deployment models (e.g., private cloud, hybrid cloud, community cloud), but the defition and the essential characteristics must be present for a service to be a cloud computing service.

Abolishing the Confusion

Abolishing the confusion should be easy: engage with a clear sense of the essential characteristics that must be present for a service to be considered as a cloud service… and be equally clear about when it really matters whether or not a service falls into the official definition of cloud computing.

Further Information

The CloudU initiative curated by Ben Kepes (@benkepes on Twitter) with Rackspace is a good resource for raising globally the level of cloud understanding. CloudU is part of the Rackspace knowledge centre at

Some other selected useful references are detailed below:

Identity Registries and Reconciliation Posture


A vendor recently asked me a question, and not for the first time, that amounted to “why won’t you buy these delicious software licenses for our amazing identity-management suite, which provides comprehensive solutions to the challenges faced by North American corporations in dealing with compliance requirements and bringing together disconnected versions of identity from across all your application systems to create sparkling, delicious, and reliable golden-record representations of all your people-constituents?” and “why is identity reconciliation so undesirable?“.

The short answer takes the form:

  1. we have a strong single-identity model
  2. we do not need reconciliation
  3. we are a higher-educational insitution
  4. we are not a North American corporation

…and the longer answer emphasises that it’s notsomuch that identity reconciliation is undesirable, more that it’s an identity-registry posture that isn’t very useful in our context.

At a gross level, there are two primary identity-registry postures, each of which can be heavyweight (i.e., all identity attributes are involved) or lightweight (only identifiers and core personal data are involved), and they are:

  • Reconciliation: Identity lifecycles take place within independent silos across a suite of application systems (e.g., Human Resources, Customer Relationship Management, Student Administration, Library, Alumni, etc) and the identity-registry reconciles those identities centrally to produce an after-the-fact analytics-based golden record (which can be used to enable single-sign-on and for roles reconciliation and compliance reporting and so forth).
  • Mastering: Identity lifecycles take place only in a central identity-registry system-of-record, and all changes affecting those identities are propagated (sometimes through an intermediary such as an LDAP directory, sometimes through publish-and-subscribe messaging, and sometimes through SAML attributes) to those downstream application systems that require identity information.

The decades-old strong single-identity model in my organisation is sustained by a heavyweight-mastering identity-registry.

As new application systems are introduced into the organisation, they are configured to prevent local/downstream changes being made to any identity information (all of which is mastered in the central identity-registry) and integrated, by one means or another, to receive only the identity information they require.

Roles, though, are another kettle of fish, and those that cannot be derived (e.g., from system-of-record information about states such as employment or enrolment information) tend to be managed locally, application-system-by-application-system.  This makes tracking the currency (e.g., is this person still entitled to this privilege?) and appropriateness (e.g., are there segregation-of-duties conflicts occurring across multiple application systems?) tricky.  As a result, there is some good value available from roles reconciliation — that is, bringing roles information together into a central repository for reporting, analysis, compliance, and for springboard-provisioning of access to extended systems-and-services.


Anti-Collaboration and the Hungry-Hippo Secret-Society

hungry hipposTrapped inside their plastic bubble-land, committed forever to competing for access to worthless inedible coloured plastic baubles that represent to them a measure of status, members of the hungry-hippo secret-society collaborate in isolation from the world around them, waiting for their plastic environments to be exhalted as wonderful contributions to the mission, the project, the policy, the business requirements, the strategy, or whatever it is these self-professed dippy maven-muppets believe they are achieving without consultation, without reflection, and without harnessing the power and good intentions of the collective.

These hungry hippos keep personal copies of their work in secretive locations, sharing only with the annointed few and the hierachico-politically-expected ones, those whose acknowledgement and annunciation they crave, and whose places they one day long to occupy by right of gift, devotion, and secret pledge.

Other hungry hippos that work this way are simply terrified, or wanna-be perfectionists, or incompetent.

From both camps, the disruptive and mischevious enterprise architects that manage to prise away DRAFT-watermarked embargoed final copies of the hippo’s work receive these gemmy gifts with form-letter strongly-worded warnings, such as:

  • please do not distribute this document any further, not to anybody else, as it is still under discussion by the team, and if this gets out before it’s been signed off then we are going to be punished heavily, especially you!

This is patent nonsense, and exactly the opposite of what’s needed: the sooner these works are distributed and visible widely, the better is the result for the initiative at hand, for the organisation involved, and for the World.

These hungry hippos must be stopped, counselled, and taught to collaborate using wiki, coauthoring, and socially-enabled tools.  As it stands, they’re routinely and repeatedly turning out expensive substandard frog-in-a-well constrained work as finished art, too late every time to undo or avoid.

Tear down the walls of the hungry-hippo secret societies!

Service-Mediation Scenarios

ESB espresso-coffee beans

Enterprise Service Bus and Espresso

One of the few really-good boutique coffee-roasters and espresso specialists in Auckland labels its beans “esb”, for “ethically-sourced beans”. It’s something of a stretch, but espresso is important and beneficial in fundamental, foundational ways not dissimilar to the importance and benefits an Enterprise Service Bus can bring to integrated organisations.

Enterprise Service Bus: Lifecycle and Hype

Enterprise Service Bus as a concept has suffered from largely-unhelpful and massive over-hyping, which began relatively early in the largely-unhelpful and massive over-hyping of everything related to Service-Oriented Architecture. This hype saw much blurring of the ESB architectural pattern with specific commercial ESB product implementations. In those early stages, an ESB-first and an ESB-or-bust ethos crept into a lot of SOA initiatives, with muddled low-or-no-benefit results.

With experience, the hype around ESB has rightsized and the use-cases have been established so the benefits of using the ESB pattern (and not using the ESB pattern) can be understood. This period of stabilisation was characterised by three significant ESB stakes in the ground:

  • 2008: ZapThink’s edict that service consumers and service providers must never communicate directly.
  • 2009: Gartner embedding the behavioural subcomponents of ESB within the SOA Backplane, at the heart of the SOA Application Infrastructure Reference Architecture.
  • 2010+: ESB patterns have become a natural, normal, and expected capabilities of application-integration stack, and there is fair expectation that some medium-and-larger packaged-applications will be shipped with ESB components either embedded within them or included as templates for open-source edgeware componentry. In turn, and likely accelerated by the rise and rise of as-a-service solution offerings, ESB federations will start to be based around quite small application-specific ecosystems, raising the ante on the needs for solid industry standards.

Enterprise Service Bus Mediation Scenarios

The ESB implementation i’ve been closely involved with has focused deliberately upon service-mediation as its primary reason for being, and has insisted on the ESB remaining fully stateless. Holding a lightweight approach on what’s expected of the ESB has enabled the foundational basics to be attended to, and for questions about orchestration, business-process-management, and longer-running integration use-cases to be deferred until they’re understood fully and their needs are well-described. In these service-mediation-first scenarios, the ESB has been brilliant. Some of the foundational use-cases where benefits have been delivered are outlined below.

  • Service Mediation: The basic layer-of-abstraction premise of raw service mediation remains the predominant benefit of the ESB architectural pattern. Service mediation provides insulation against change, flexibile interoperability, and support for versioning. In addition, ESB platforms support monitoring and management, security, and metrics-collection.
  • RESTful: Faced with legacy integration middleware incapable of dealing with RESTful web services, and needing to deliver messages into a RESTful-only packaged application, the ESB was configured to provide a WSDL-based web-service proxy to the RESTful endpoint.
  • Document Style: Faced with the rpc/encoded web-service provided by a government agency, the ESB was used to create a document/literal proxy service, managing the translations between the two, and enabling modern libraries to be used by the bespoke applications needing to call the agency’s web-service.
  • Security Injection: Faced with a third-party communications service structured aroud the concept of one-application-user-for-each-organisational-customer, but needing for security and for activity-based-costing reasons to separate out the calling users, the ESB was used to require username-and-password tokens for access to its proxy service. After validating the caller locally, a parameter was passed in the service calls to the third-party service, and that parameter appears in the billing reports, enabling costs to be apportioned internally, and forcing internal governance processes to be followed when new users of the third-party communications service are established.
  • Security Injection: Faced with the need to provide differently-privileged web-service clients with different sets of attributes from the calls to the same business services, the ESB was configured to pre-process web-service results through XSLT masks to obscure or remove attributes specific clients are ineligible to receive. For example, an identity web service might return attributes such as the IRD/ATO/SSN tax-file numbers, or birthdates, or information about disabilities. Using XSLT masks, only those clients entitled to receive those attributes are provided with them.

Selected Highlights