EA as a Cultural Navigation Practice

Holding the balanced view and perspective

“I keep trying to teach the business about enterprise architecture but they just don’t get it!“

A former colleague from a nearby university would periodically invite me to coffee for a lengthy discussion about the frustrations of working as an enterprise architect in higher education. Each time, she’d end up feeling recharged with optimism and reset sufficiently to go another round, promising to stop trying to “teach the business about enterprise architecture”… until the next time.

At the heart of this experience is the unique place where enterprise architecture stands, occupying the interstitial space bounded by the strategy and execution dimension and the technology and business dimension. The balanced view and perspective that enterprise architecture provides must flex in response to the different situations it encounters. In TOGAF terminology, we must have the ability to construct narratives and views that are consumable by and address the concerns of our stakeholders, acknowledging the viewpoints they occupy¹.

Although the stories we tell and the artefacts we use will flex situationally, there is still a need for consistency that pervades the work of an enterprise architect — there are things that must be so. A large part of what we do is curation, preservation, and gentle governance. We work to protect and sustain the vision and truths, outcomes and goals, patterns and ways of working. Just like the role of travellers in a world café, enterprise architects serve as “ambassadors of meaning”², carrying, caring for, and storytelling the strategic goals and aspirations, the guardrails and guidelines, and the core values of the institution as they move across situations and into new conversations.

What we talk about when we talk about enterprise architecture

To earn and retain its seat at the table, enterprise architecture must be an identifiable practice offering service, guidance, and consultancy not provided by other contributors in the wider organisation,  Understanding and communicating what enterprise architecture is and does (and, crucially, what enterprise architecture is not and does not do) acknowledges and reduces the potential for confusion and for operational friction with teams and functions such as infrastructure engineers, application builders, solutions architects, cybersecurity experts, project managers, and business analysts.

Holding a sense of self and place, caretaking with purpose the balanced view and perspective necessary for enterprise architecture to build alignment and foster desirable business-outcome value, requires sustained effort.  Curiosity and humanism are central to that effort, consistently storytelling the “why”, creating connections between disparate people, teams, and activities, and curating linkages between change initiatives, architecture decision-making, and the institution’s North Star.

When enterprise architects stray from holding the recognisable and useful balanced view and wide perspective, instead giving technical-practice specialists the impression they are not so different from them, that they could perform their roles or be their boss, and invariably fall into the “uncanny valley”³ where trust evaporates, relationships are awkward, and the seat at the table is lost.  Specialised people and teams should feel that “my enterprise architecture listens to us, knows what we do, understands the challenges we face, and represents us faithfully at the other tables”, rather than “my enterprise architect pretends to know better than us what we do, gives us weird instructions, doesn’t understand what we do, and is getting in the way”.

Exactly what consistency looks like for your enterprise architecture practice will necessarily vary from one institution to another, from one engagement to the next, and over time as the maturity and agency of the practice waxes and wanes.  Throughout all these changes remains the need to be clear about and to communicate what it is that enterprise architecture brings to the table.  What is your role at this particular table, at this particular time?  How will fulfilling the goals and expectations of your role, as an enterprise architect, contribute to achieving desired business outcomes?

Honouring protocol and procedures at the table

“jeff is passionate and knows what he is talking about and demonstrates
university citizenship, but I wish he would stop and listen sometimes!“

This gift of feedback came from one of our senior executives, second-hand, through my boss.  After my initial reactions of shock and embarrassment subsided, the message became clear: slow down, check in, engage in active listening, seek feedback, confirm alignment, assume less, retest often, wrap all of this in mutual respect… and not just with this one stakeholder, but everywhere!  My approach started cautiously and experimentally and was, frankly, clumsy, stopping frequently and making eye contact and saying something like “I am listening to you, and want to play back what you have shared just now to check my understanding”.

That it was clumsy was immaterial: the effects were positive and instantaneous.  Suddenly there was much more space to have the necessary conversations, and much-faster iteration to locate key points of agreement and key points of difference, leading straightaway to better conversations and more-productive engagements and stronger outcomes.  Without purposeful listening it becomes very difficult to hear and harvest other views and opinions, rendering one of the crucial ingredients of effective leadership completely unattainable… and enterprise architecture is all about effective leadership.

While at the table, pay attention to your colleagues and the positions they occupy, noting that these positions will change frequently over the course of a discussion.  Keep track of who is for and who is against the decision to be made.  Keep track of who is observing or abstaining, and ensure that everybody has the opportunity to declare their position.  Keep track also of where you stand yourself, and of what the desirable outcome is from the enterprise architecture perspective. Kantor’s four-player model⁴ is a valuable framework for this purpose: who is moving, who is following, who is opposing, and who is bystanding?

All of those roles are active, and any person can switch modes at any time.  As an enterprise architect sitting at the table you will have to be confident and capable at being able to move, follow, oppose, and bystand purposefully and at the right time.  Sometimes it is necessary to defer aspects of the conversation that don’t affect the direction of travel and that won’t cause later relitigation of any decisions made.  If you’re tempted but unsure about making a statement, ask yourself these key questions: does it have to be said at all?; does it have to be said right now?; does it have to be said by me?

There exists a dazzling array of tables

Beyond holding design-authority privileges for usually-quite-specific matters related to implementation, enterprise architecture has no power of mandate and no ability to veto organisational decisions about investment, direction, or approach.  This situation shapes the practice of enterprise architecture into an endeavour that is long-run in nature, requires significant trust and influence to be earned and sustained, and provides recommendations, advice, and guidance in the form of consultancy.

Having earned a seat at the table, look around!  At which table are you seated?  Who else is there with you, and what is each of their roles as stakeholders: how interested do they need to be, and how supportive (alternatively, how disruptive) are they able to be?  Holding awareness of your enterprise context, the maturity and aspirations of your organisation⁵, and the type of practice you have, what defines the success of your involvement?  Why are you sitting at this table at this time: what value will you and your enterprise architecture practice work purposefully to contribute?  What difference will be made by you being there at the table?  What difference would it make if you were not there at the table?

Of course, “the table” is not only a physical meeting with chairs and a table!  A discussion thread happening by email or messaging, a virtual meeting, a distributed collaboration, a passing engagement at the water cooler, a daily stand-up or any of the Agile ceremonies, all of these situations are tables in their own right, and our messaging and behavior at any of them contributes to the trust and influence and ability to do work and create value that our practices can earn and hold.

Navigating the dazzling array of tables adds another dimension to situational awareness and personal leadership.  The practice of enterprise architecture continues to evolve from being the  back-office creator of detailed technical specifications through business-outcome-driven approaches and decision-making about technology through serving as internal business consultants⁶.  Imagine the necessary differences between the storytelling, conversations, and engagement styles at each of those waystations.  Imagine the different positions, concerns, and alliances that exist between the people sitting at the tables alongside you.  Fail to navigate and honor these styles and expectations at your peril!

To create desirable outcomes and better serve their institutions, enterprise architects must hold a firmly-grounded sense of place and navigate respectfully the myriad of contexts in which they work.  That’s a challenging set of responsibilities, requiring expertise and craftwork to weave the essential threads of what enterprise architecture is all about, and to do that in a way that fosters effective and meaningful contributions while bringing people together in warm and constructive alliances.

---

1.  The Open Group (2022) _The TOGAF® Standard, 10th Edition_, available at https://pubs.opengroup.org/togaf-standard/architecture-content/chap03.html#tag_03_04 ↩︎
2. The World Café Community Foundation (2015) _A Quick Reference Guide to Hosting World Cafés_, available at  https://theworldcafe.com/wp-content/uploads/2015/07/Cafe-To-Go-Revised.pdf ↩︎
3. Caballar, I.D. (2022) _What Is the Uncanny Valley?_, IEEE Spectrum, available at https://spectrum.ieee.org/what-is-the-uncanny-valley — Creepy robots and the strange phenomenon of the uncanny valley: definition, history, examples, and how to avoid. With acknowledgement to the work of Graeme Dunlop, formerly at The University of Melbourne. ↩︎
4. PeopleTalking (2022) _Structural Dynamics_, available at https://peopletalking.com.au/project/structural-dynamics/ ↩︎
5. Phelps, J. (2020) _Architecting the Architecture: Necessary Steps for Setting Up an EA Practice_, EDUCAUSE Review, available at https://er.educause.edu/articles/2020/10/architecting-the-architecture-necessary-steps-for-setting-up-an-ea-practice — Colleges and universities that identify and understand the drivers, goals, and environmental factors of an enterprise architecture practice can create the structure needed for EA to be successful. ↩︎
6. Brand, S. & Blosch, M. (2022) _13 Best Enterprise Architecture Practices to Ensure Program Success_, Gartner Research, Article ID #G00767656, available at https://www.gartner.com/document/4014142 — Many EA practitioners follow “worst practices” rather than best practices. Enterprise architecture and technology innovation leaders should follow our 13 best practices to ensure EA program success. ↩︎

A digital dinosaur, and enterprise architecture

A digital dinosaur.

The Council of Australasian University Directors of Information Technology¹, “CAUDIT”, provides valuable support and governance to several communities of practice operating across more than sixty member organisations.  The CAUDIT Enterprise Architecture Community of Practice is the longest-running of those communities, and is holding is thirteenth annual in-person symposium meeting in November 2018 at Curtin University in Perth, Western Australia.

During last year’s event, hosted at Queensland University of Technology, a bright and entrepreneurial architect from The University of Queensland asked me to sit for an informal discussion broadly on the topic of “what is enterprise architecture?”, this to be the first of a series of such discussions to be captured and published to the community as a resource.

In the end, mine was the only video created — i located it only recently, almost a year later to the day, and thought it might be as well to publish this transcript of what i said in answering the question “what is enterprise architecture?”.

However, i’m doing this with a heavy sense of awkwardness: i’m mumbling and distracted, and foolishly suggested the discussion be held before the great wall of digital dinosaurs at QUT’s incredible “Cube” facility², so dinosaurs are moving and roaring and lowing in the background, something i thought would delight my young son when he later saw the video.

Nevertheless, here’s what i said about enterprise architecture, one year ago, and again demonstrating my strong belief in Brenda Michelson’s near-decade-old declaration that “the ultimate outcome of enterprise architecture is change-friendly capability delivery”⁴.  The transcription of the two-minute-long video³ follows here:

The role Enterprise Architecture plays in my organisation is really based around the classic Twitter competition of what Enterprise Architecture is and does, and the primary function of Enterprise Architecture is to generate change-friendly capability delivery, and that means you can use things and capabilities you create in unexpected and unanticipated ways, and it means that when scale or extensibility is required then the capabilities you created can flex or be outsourced or be scaled appropriately to deal with those things, so change-friendly capability is the ultimate outcome of good Enterprise Architecture.

We also find that Enterprise Architecture is really important in trying to work with senior business leadership to understand the relationship between the investments they make in strategic projects and the outcomes they get for the business both in terms of customer focus but also in terms of alignment with organisational strategy.

Enterprise Architecture of course is strategy, there’s almost no difference between the two, so making sure that we’re involved right up front: provoking, stretching, and testing organisational strategy from an architecture perspective, because what we have is an unrivaled view of the whole organisation, so the it’s the glue in addition to being the family therapy and social work.

The Enterprise Architecture function at the University of Auckland is also involved in assessing and understanding the introduction of new technologies, working with those to ensure that they fit sustainably into the organisation, and then establishing enough of a pattern around them that they can be handed over and fit into the whole delivery stack of the organisation across the delivery side.

So, EA is the glue, it’s all about change-friendly capability delivery, and it’s about alignment of investment with business outcomes for good.

On reflection, some of that doesn’t really stand up to sensible thinking (e.g., there’s no difference between enterprise architecture and strategy), and the recognised significance of soft skills for architecture people to be effective can be characterised in better ways than as “family therapy and social work”.  Still, the community project seemed sound at the time, and having these words now written down a year along from when they were captured provides a sense of having attended to something that needed doing.

1. The CAUDIT website is at https://caudit.edu.au/
2. QUT’s Cube “…is one of the world’s largest digital interactive learning and display spaces dedicated to providing an inspiring, explorative, and participatory experience of QUT’s Science and Engineering research”: https://www.thecube.qut.edu.au/
3. The resulting video has been published to YouTube and is available at https://youtu.be/GCrR3qXmjL4
4. Brenda Michelson, @bmichelson on Twitter, http://www.elementallinks.com/ website, and the story from 2010 of the enterprise-architecture-in-140-characters definition: http://www.ebizq.net/blogs/bda/2010/04/mckinsey_agrees_outcome_of_ea.php

A decadesworth of consumer technology.

1991

i did not keep a television for the twelve years i spent living alone, preferring books and music to the ghastly and limited broadcast offerings of the 1990s.

2003

When we first started living together, my wife-to-be produced her elderly SONY Trinitron television, a cubic-metre of black plastic shrouding a buzzy, hot, squealing cathode-ray tube with its fuzzy, staticky, swollen, heavy, greyish, screen.

2006

In the relatively-wealthy period we enjoyed before having children, we splashed out on a beautiful, if modestly-sized, top-of-the-range high-definition SONY Bravia flat-screen LCD television, cast the old cathode-ray unit into the ocean, and marvelled at the details and the colours of our new television.

2015

The SONY Bravia television had held up well, despite my young daughter scratching its screen by driving and scouring a plastic-toy DottyWot¹ across its surface, and despite her malevolent cousin smashing its remote-control unit with a hammer.  However, just before Christmas, the picture started turning pink and blue and becoming frustratingly-unwatchable a greater proportion of the time than not.  We held out for a few weeks.

2016

A replacement television had become necessary, so we bought another SONY Bravia, this one with built-in wi-fi and a big red “NETFLIX” button in the centre of its remote control.  This new television:

• was much cheaper
• has a bigger screen
• has higher resolution
• is smarter
• weighs less than half
• consumes less than half the power

…than the old television, and it has been embraced as a wonderful thing by the whole family.  The characteristics of the two machines are:

Specification	Old Television	New Television
Model Number	KLV-V26A10	KDL-32W700C
Date Manufactured	JAN 2005	OCT 2015
Date Purchased	JUL 2006	JAN 2016
Price Paid	NZD$3,150	NZD$747
Screen Size	26″	30″
Weight	17.6kg	6.8kg
Wireless Connectivity	none	802.11a/b/g/n
HDMI Inputs	1	4
Power Consumption	145W	62W
Screen Resolution	1366×768	1920×1080
Made In	Japan	Malaysia

What strikes me heavily is the size and nature of the difference a decadesworth of progress in consumer technology has made, and this is a very-mainstream and very-pedestrian example of that progress — there is an unimaginably-vast quantity more to come.

 

Notes:

1. DottyWot is a character from “The WotWots”, a children’s television programme made in New Zealand: https://www.wotwots.com/

All We Like Sheep Have Gone Astray

Unsettled, the haplessly-institutionalised incumbents huddled together for warmth, two to a cubicle, cruel flickering artificial light obliterating any capacity they once might have harbored for self-actualisation or for problem-solving, casting an especially-stark relief upon their miserable, wasteful, angsty souls.

They were unsettled by the juggernaut paperweight reputation of the new shepherd coming to guide them, probably to slaughter them, certainly to restructure them, and this new shepherd, this new shepherd was certified!  This new shepherd with a string of certifications long as a donkey’s tail: TOGAF, ITIL, PRINCE2, PMI, COBIT, MSCE, and a beginner’s first-aid certificate and some first-year classics and ancient history university study as a bonus.

Their fearfulness was palpable and paralysing and visceral, but, in the end, thoroughly unwarranted, for this new shepherd was just a person, just a person with the same pains, hopes, and fallibilities the rest of us have.

There continues to be much over-hype about certifications in IT, particularly about enterprise-architecture certifications, and particularly about TOGAF certification.  Demonstrating core knowledge in a domain or discipline through a standardised assessment process is a good thing, and establishing reliable credentials is a good thing for the profession of Enterprise Architecture.

Where the simple system of “credentialled = worthy” breaks apart is the point at which the credential itself becomes imbued with mystique and desirability and is viewed as an end in itself.  For enterprise architecture, where the professional practice must be adapted from one vertical to the next, from one organisation to the next, from one practitioner to the next, and from one type of engagement to another, having a detailed map to follow is neither possible nor sensible.  What’s needed is a compass, not a map¹, and none of the major enterprise-architecture frameworks currently provide compasses or maps.

Gartner summarises the current state of affairs nicely in the 2014 edition of the Hype Cycle for Enterprise Architecture², including observations that:

• certification’s value is unclear to organisations
• certification’s value is unclear to individuals
• certification is a good thing to have on your resume
• certification implies almost nothing about proficiency

The always-insightful, always-thought-provoking Tom Graves makes crucial observations about skills and (or versus) certifications in his Saving enterprise-architecture from itself post³:

• certification has become a commonplace recruitment filter for enterprise architecture roles, and this approach weights certification (which is typically no more than a few-days-long short course) overwhelmingly and disproportionately more heavily than years of applied experience working as an enterprise architect
• certification in enterprise architecture frameworks ignores the enormously-important complement of soft skills (the communication, leadership, collaboration, and adaptability) that are essential for success as an enterprise architect — they do this because the enterprise architecture frameworks themselves are barren of soft-skills content

Jason Bloomberg’s new Bloomberg Agile Architecture⁴ is a great new example of practical, adaptable, and flexible applied enterprise architecture.  This new technique differentiates itself from the traditional heavyweight do-everything subtractive frameworks (i.e., you discard pieces of the framework you think  you don’t need) by instead taking an additive approach that incorporates elements, artefacts, and capabilities as they are found to be required in order to deliver a particular business outcome.  There’s much to like about this approach.

The danger for enterprise architecture is that the academic energies wasted mewling sheeplike after the frameworks and the certifications are preventing us from forming constructive connections with our customers, partners, and stakeholders, and inject bedazzling interfering distractions that prevent fulfilling the mission and promise of business-outcome-focused enterprise architecture.  Curiously, the more of us that become certified in a common framework, the better the chances of those frameworks being improved, of architects developing common vocabulary and process, and the better the chances of certification’s value becoming clear and visible.

The frameworks have much to contribute to and provide anchor for the practice of enterprise architecture, and there is value to be found in them, but leading in a still-diverse and still-immature profession with overemphasised focus on the merits of certification as a rite of passage and entitlement to speak is leading all we, like sheep, astray.

 

 

 

 

1. Principle 3 here is very nice: “compasses over maps” = MIT-Knight Civic Media Conference, 2014, Joi Ito’s 9 Principles of the Media Lab, http://vimeo.com/99160925
2. Betsy Burton & Philip Allega, 2014, Hype Cycle for Enterprise Architecture, 2014, http://www.gartner.com/document/2804819
3. Tom Graves, 2013, Saving enterprise-architecture from itself – 3: Skills and certification, http://weblog.tetradian.com/2013/11/11/saving-ea-from-itself-3-skills/
4. Jason Bloomberg provides essential reading for enterprise architects in these two pieces:
   1. 2014, Is Enterprise Architecture Completely Broken?, http://www.forbes.com/sites/jasonbloomberg/2014/07/11/is-enterprise-architecture-completely-broken/
   2. 2014, Is the BAA Technique an Architecture Framework?, http://intellyx.com/introducing-the-bloomberg-agile-architecture-technique/is-the-baa-technique-an-architecture-framework/

Line-In-The-Sand Leadership

We know that attitude, culture, and engagement underpin the performance of a team.  Despite knowing this, the announcement yesterday that four key players in the Austalian cricket squad currently touring India will be excluded from selection to play in the third test-match of the series was chillingly clear and startlingly decisive^1,2.

Together, the coach, captain, and team manager triumvirate detailed the situation, the behaviour, and the impact on the team — the essence of which is reproduced here, statement-by-statement, and with the cricketing context removed:

1. This is a line-in-the-sand moment.
2. We have given the team absolute clarity.
3. We have given the team a huge amount of time to buy into with what we want to achieve.
4. We have given a vision to the team that is spelt out.
5. We’ve given an expectation that is spelt out.

The four suspended players failed to meet the expectation, which of itself could be viewed as trivial, and the consequences punitive, but the leadership fundamentals here are strong, sound, and clear:

• attitude and culture really matter
• engagement is crucial for performance
• every team member must be on board
• clarity of vision, values, strategy, and aspirations is essential
• opportunities to live the values and buy into the vision must be provided
• clarity of expectations is essential
• good leadership involves taking hard decisions, and acting upon them

…and, crucially:

• individual performances are too expensive if they come at a cost to the team culture

i’m often finding analogies between the honourable and proper form of cricket (the five-day test match) and the execution of projects and other change initiatives, though not always very good analogies.  The variety of roles required within a cricket team necessarily mean that different team members have different specialisations, yet must share and be bonded deeply by common values.

Here, we’re seeing a spectacular demonstration of long-term thinking and strong leadership, setting the agenda not for the next two test matches, but for years to come.  It’s a risky, courageous, galling, dramatic, and bold step, taken to bolster, sustain, and grow the team as a whole.

It’s leadership.

1. Barrett, C. (2013) Up In The Air: Watson flies home after Test axing, The Melbourne Age at http://www.theage.com.au/sport/cricket/up-in-the-air-watson-flies-home-after-test-axing-20130311-2fw9i.html
2. Coverdale, B. (2013) It’s Not Just About One Incident, ESPN cricinfo at http://www.espncricinfo.com/india-v-australia-2013/content/current/story/624571.html

Attack of the Vegan Zombie Business Cases

The Business Analyst and the Project Manager have yet another impossible timeframe forced upon them, which they accept.  Faced with the prospect of losing the confidence of their Project Sponsor, they somehow manage to squeeze out their Business Case.  The Business Case is such a success that they circulate it to the usual suspects for formal review.  However, when a nosy enterprise architect begins poking around in the details, he finds more than he bargained for!

Just like the horrible undead creatures from in B-grade horror movies like Attack of the Vegan Zombies!¹, the business cases keep coming through the door and through the email, and they are unstoppable, fully-formed, dangerous, and perfectly hideous.

• The business cases arrive after being bred in captivity, never before having seen the outside world or a strategic context, and they are packed with impenetrable, unusual, misused, and idiosyncratic language: their intentions are unclear, and we are unsettled by not being certain what they are requesting or justifying.
• The business cases arrive after ten o’clock at night, sixty dense and confused pages long, demanding detailed review before morning to justify a case for change requiring substantial investment.  In the dead of night we unwrap them, afraid at the what inevitably lies within, and as powerless to change their course as the archtypal naked home-alone victim showering behind a flimsy plastic curtain as the evil murderer approaches.
• The business cases arrive packed with imperatives: we must make this investment because the life, sustainability, and reputation of the business depends upon it, and because we were denied unfairly last time we asked, please!  The very essence of life and death is at your feet, morality and emotion and heartstrings are tugged and implored.
• The business cases arrive in generalisation-based disguises, cunning wolves dressed as sheep: the case for change is supported unequivocally by the “really expensive” support that will be avoided, by the “drastic risk reduction” that will result, and by the “hugely increased user experience and effiency gains” the organisation will receive from undertaking the work, none of it quantified, well-imagined, or offered with a timeframe in which the benefits will be realised.

Here, now, in 2013, we should be good at business cases, both at creating them and at approving or rejecting them.  Much too often, a business case comes along as an urgently-needed administrative chore to mop up paperwork requirements after an investment decision has been made.  The business cases are bad! However, there are some practical steps to start turning this around:

1. Collaboration: business cases must not be allowed to grow in isolation, not even to first-draft condition, because so much is set in stone by the time first-draft condition is reached.  Creating a business case must be an open, social, collaborative endeavour.
2. Context: business cases must be created with context, which means that the projects and initiatives for which cases for change are made must have their own context devolved to the business case and to the team charged with its creation.  The business-case-initiation phase modelled by Gartner² includes the tasks:
   • define how the initiative addresses business strategy
   • identify business case stakeholders
   • identify business case audience
3. Betterment: initiatives such as the New Zealand Government’s Better Business Cases³ model (based upon similar models in the UK and Australia) seek to improve the rigour and repeatability of good business cases that support clearly the case for change across five domains: the strategic case, the economic case, the commercial case, the financial case, and the management case.

There is good reason to hope and expect that the quality of business cases will improve, but achieving that improvement does require soup-to-nuts involvement of enterprise architecture and program/portfolio governance teams.  It’s when the business cases appear with a shock factor that things invariably go bad, not least because it’s all too late to recover.

1. Attack of the Vegan Zombies (2010) synopsis from IMDb at http://www.imdb.com/title/tt1380852/plotsummary
2. Ganly, D. (2012) Use a Robust Business Case Process to Avoid the Seven Common ERP Pitfalls. Gartner Research, Article ID #G00232378.
3. New Zealand Government (2010–) Better Business Cases, http://www.infrastructure.govt.nz/publications/betterbusinesscases

“Fairy Bright Eyes”, Projects, and Decay

“Fairy Bright Eyes” is an installation by Ryan Monro, one of a dozen artworks in Auckland’s Learning Precinct Micro Sites initiative¹.  A unexpected curiousity in an unusual location on a university campus, this piece represents beautiful aspirations and their subsequent inevitable decay:

• A chandelier hangs over an alleyway. At first it symbolises luxury and hope but as it degrades over time it becomes a symbol of dystopia.

i’ve recently encountered a number of situations in which problems have appeared or changes are needed to the deliverables of projects that were closed as success stories, and the organisation’s ability to address those problems or make those changes has been wavering between absent and resentful, and for extraordinary, though predictable, reasons including:

• the project didn’t deliver that function, and we’re forbidden to work on it now as a business-as-usual activity.
• the project was outsourced, and nobody here knows how it works, and the documentation we were promised never materialised.
• the project went live, but there was a lot that got moved into Phase 2, but they spent all the money on Phase 2 fixing problems with Phase 1, and now we don’t have anything that was promised in Phase 2.
• the project delivered a product, but the only person that knows how it works has moved onto another project, and we’re not allowed to speak with him.
• the project couldn’t deliver that integration because we failed to overcome political problems with the other system owner, and now there is no funding left anyway.

At once, i was reminded of the chandelier and its spectacular decay from a thing of sparkling beauty into an exhaust-tarnished relic, and reminded of two essential takes on the problem with projects and their definition of success:

• energy, funding, and resource are assembled and brought to bear in the greenfields stage of a project, and those elements, along with the peculiar nature of the early greenfields condition, enable projects to move quickly and make initial changes and delivery with reasonable agility… but subsequent changes are soon required on top of initial changes, and then the project ends, and a prolonged stagnation period ensues².
• the success of an application project can be judged only by its long-term ability to deliver business benefit and by the change-friendliness of its capability delivery³, which is determined by the extent to which its non-functional characteristics have been understood and quality-assured⁴.

As an industry, we’re doing a terrible job of delivering application projects.  A big part of the solution to turning this terribleness around and improving these projects must come from the enterprise architecture discipline, embedding good behavoiurs, patterns, principles throughout the project lifecycle, from inception through design and delivery to long-term benefits realisation and, eventually, into managed decay.

 

 

 

1. Various Artists. (2010) Learning Quarter Microsites, described at http://www.aucklandcouncil.govt.nz/EN/newseventsculture/Arts/publicart/Pages/learningquartermicrosites.aspx
2. Krafzig, D., Banke, K., & Slama, D. (2005) Enterprise SOA: Service-Oriented Architecture Best Practices. Prentice Hall. ISBN 0-13-146575-9
3. Enterprise Architecture in 140 Characters, Brenda Michelson, Elemental Links, http://www.elementallinks.com/2010/02/17/enterprise-architecture-in-140-characters/
4. Kyte, A. (2011) In Application Projects, ‘Success’ Needs Many Definitions. Gartner Research, Article ID #G00210218.

“What value will a Solution Architect add to this?”

After some prompting, the technical requirements arrived for architectural review.  They had been prepared from a well-intentioned place and under the pressure of project timelines.  Scanning through them revealed serious problems: these requirements were much too far progressed, and were based upon several fundamental anti-patterns.  Needing to deliver some new information from one ERP system to another, the proposed integration solution:

• specified silent discards in favour of raising alerts when errors were detected
• favoured unsustainable side-door integration techniques over the use of established patterns
• was disconnected from the business requirements it has to deliver
• specifies data-exchange and transformation rules at the wrong layer of the stack

These are unacceptably-bad things, and while their origin is understandable and of an environmental and historical nature, rather than of an individual or other nature, they must be addressed, and the course proposed redirected towards simple compliance with basic established delivery patterns.  This work is not supporting an isolated endeavour, a proof-of-concept experiment, or an early innovation — this is a mainstream production deliverable where there is genuinely no latitude for managed diversity.

Perhaps inevitably, the project machine responded as follows, heavily paraphrased:

1. why are you making us have to do this properly?
2. what is the value of involving a solutions architect?
3. don’t you know we’re busy?

The spectrum of governance ranges from assistive governance through to directive goverance, in both proscriptive (you must not do these things) and prescriptive (you must do these things) flavours.

While there might not always be uniquely-right or best-ever answers and solutions, there is a sense of universal truth and rightness here, and sometimes the architecture function must adopt a directive position, generally when assistive positions have failed to achieve a sustainable business-value-driven outcome.

Facilitating the use of established repeatable patterns, ensuring change-friendly sustainable outcomes, and sometimes veering into directive governance, that’s the value of a solutions architect.

busoto is collaboration

In 2011, and again in 2012, while preparing to cofacilitate with Ric Phillips¹ a workshop about collaboration across an enterprise-architecture community of practice, we were reminded with jarringly clarity that the word collaboration is misunderstood and misused, and that unhelpful behaviours result from this misunderstanding and misuse.  Under the banner of collaboration are in fact three broad classes of behaviour:

1. Connecting
2. Sharing
3. Collaborating

…and the expectations upon participants and on the elements needed to support those behaviours vary greatly from one broad class to the next, as:

1. Connecting is simply establishing and in some way monitoring connections between people in environments such as LinkedIn and, to a certain extent, Twitter and Yammer.  Connecting gives rise to ambient intimacy² — knowing what is happening, knowing something of what your peers are doing.
2. Sharing is making available to others some or all information, decisions, and other artefacts (e.g., strategies, templates, documents, diagrams, code) that are generated by doing work. Sharing can be mediated by websites, blogs, Twitter, and so forth.
3. Collaborating is the deliberate cooperative creation of something new: new products, new artefacts, new understanding — in any form, new value.

Selected good definitions of collaboration include:

• two or more people working together towards shared goals³
• creative coordinated goal-oriented⁴
• working together to achieve a goal⁵

…and three random examples are offered below:

• busoto is a new portmanteau of the phrase build something together, illustrated by the drawing at the head of this post, which my five-year-old daughter and i built together deliberately.

• Wai Notes^{6, 7} is a music album containing early/demonstration versions of songs that were recorded by Will Oldham and Dawn McCarthy by exchanging tapes in the postal mail.
• A group of architects from different organisations obtain local sponsorship to work together to define and create business capability models for their sector.

Collaboration, busoto, is a deliberate and identifiable behavioral style.  It builds upon, depends upon, and is a higher form of connecting and sharing. Communicators and collaborators must acknowledge and stay actively aware of the difference between connecting, sharing, and collaboration.

1. Ric Phillips and his excellent eapatterns blog at http://eapatterns.tumblr.com/
2. Ambient Intimacy coined and defined at http://www.reboot.dk/page/1236/en
3. Ephraim Freed’s August 2012 post What Collaboration Really Means at http://www.thoughtfarmer.com/blog/2012/08/14/what-collaboration-really-means/ includes a useful list of behaviours often confused with or labelled as being collaborative, but that are not collaboration.
4. Jane McConnell’s May 2012 post Clarifying the word “collaboration” to reduce confusion and conflict at http://netjmc.com/social-collaboration/clarify-to-reduce-confusion-and-conflict includes some helpful models indicating how collaboration fits into the digital workplace and other work and organisational patterns, alongside intranet/content and people-connectedness.
5. The wikipedia definition at http://en.wikipedia.org/wiki/Collaboration
6. Wai Notes at Drag City http://www.dragcity.com/products/wai-notes
7. Wai Notes at Wikipedia http://en.wikipedia.org/wiki/Wai_Notes

The Architecture For This Project Is Out Of Scope

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 delivery¹) 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 Management²) has transformative potential for good
• noting signs that enterprise architecture and P3M practices can deliver better business outcomes working together harmoniously³

…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.”⁴

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, http://www.elementallinks.com/2010/02/17/enterprise-architecture-in-140-characters/
2. The Project, Programme and Portfolio Management InfoKit from JISC http://www.jiscinfonet.ac.uk/p3m 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, http://my.gartner.com/portal/server.pt?gr=dd&ref=shareSummary&resId=2173516 gives a pragmatic and actionable set of best-practice suggestions for aligning enterprise architecture and P3M teams and initiatives.
4. @howardtaylor on Twitter at https://twitter.com/howardtayler/statuses/260944798167482368