Planting trees
That’s a large part of what I do, I guess – planting trees, metaphorical and literal. Why? Well, perhaps the best reason for doing so is in a lovely tale I came across the other day. One of the Oxford…
Aggregated enterprise architecture wisdom
That’s a large part of what I do, I guess – planting trees, metaphorical and literal. Why? Well, perhaps the best reason for doing so is in a lovely tale I came across the other day. One of the Oxford…
This all started when I first touched base with software architecture back in the 90’s, since then I’ve been drawn to the shaping of concepts to produce some sort of thing, be that business, software or technology. During the last four years I’ve been directing my inquiry into the field of enterprise architecture using the […]![]()
Chronic underinvestment in IT is now more prevalent given the economic climate of the past few years. Excellent post on the critical concept of technical debt. Technical Debt – What it is and what to do about it.Filed under: Business … Continue reading →![]()
Big Data is the Big Thing at the moment. It won’t be ten years from now. And not because we tackled the technical aspects of handling it, or created huge business intelligence systems capable of harvesting the treasures hidden in it. Or because it has become generally accepted and arrived at Gartner’s plateau of productivity. […]
One of my interests is coaching, I’m a real believer in the positive effect good coaching can have on work performance, morale, clarity and general well-being. I also believe the techniques used in coaching is an essential part of the toolkit of an enterprise architect.
A few weeks ago I was talking to a colleague who happens to be an experienced coach who is also starting to explore enterprise architecture and specifically TOGAF. I’ve got a love/hate relationship with TOGAF, but it was really interesting to hear how my colleague, coming from a coaching perspective had approached TOGAF. He is now using the TOGAF ADM as what i’d term, a ‘coaching compass’. The idea of bringing up structure/method/map to coaching isn’t a new concept, but it hadn’t hit me how well the togaf adm (or at least the structure it implies) lends itself to being used to orientate a coaching scenario.
I thought this was an interesting way of viewing the ADM and coachign, so thought i’d jot down some of my thoughts off the back of this conversation.

Lets take a look at the ADM (and I warn TOGAF purists i’m going to take some poetic licence with the ADM) from a coaching perspective.
A coach could use the ADM from two different perspectives, either as a compass to guide an ongoing engagement (of one or more coaching sessions) or as a compass for a specific session
Here are some thoughts as to how each phase might translate into a coaching context
Prelim
Creation of coaching ‘contract’ between coach and coachee
A. Architecture Vision
Explore the goals of the session/engagement
B. Business Architecture
Explore possible target state of the people/process aspects of the goal(s)
C. Information Systems Architecture (apps and data)
Explore the tools (in the widest sense of the word) that might enable achievement of the goal(s)
Explore the information that might be required to achieve the goal(s)
D. Technology Architecture
Explore the fundamental structures that might need to be put in place to achieve the goal(s)
E. Opportunities and Solutions
Having taken phases a-d into account, explore the opportunities presented by what has been uncovered and the possible solutions that may help achieve the goals identified in phase A
F. Migration Planning
Having decided on a solution, explore the approach to implementing to achieve the goal(s) and the steps (transition architectures :)) to implement.
G. Implementation Governance
Ensure the planned migration and the chosen solution remains on track, this phase could take the form of simply returning to the migration plan at each successive coaching session
H. Architecture Change Management
The landscape and context for the coachee will change over time and between sessions. This is the opportunity to assess changes to the context that may affect the ways in which the coachee’s goals are to be achieved, or even the nature of the goals themselves.
Requirements
Instead of requirements, think of every phase feeding into testing/validating/changing the goals defined within phase A.
This is just a sketch of how the ADM might be interpreted in a coaching context, i’m not saying this is perfect, maybe its not even useful. but I think its an interesting approach that i’ll explore more during my coaching practice.
“Don’t anthropomorphise computers – they hate that!” – that was the text of a great graphic I found on Flickr, and that I’ve used in various slidedecks since. Yet might it actually be a good idea sometimes to do just…
Post co-authored by Rob Shelton, PwC’s Global Innovation Strategy Leader Last year if you asked a CEO what he or she is doing to achieve growth, the answer would have been investing in China. This year the answer is innovation. Business executives are banking on bold innovation to meet aggressive growth targets, so they are taking innovation more seriously than ever before. In the spirit of Peter Drucker who said, “innovation is work,” business executives […]
If you liked this, you might also like:
Many of you may be familiar with the problem. Especially if you use database applications in your everyday jobs. Sometimes the system stores things that are not entirely correct, or even blatantly untrue. Data pollution; that is what we call it. Somet…
I am excited about Accelare’s new software product: The Capability Manager. Accelare has announced the general availability of the WhatFirst™ Capability Manager, a new tool for creating and managing business capability models, built on the Microsoft SharePoint 2013 platform. WhatFirst™ Capability Manager is designed as a simple to acquire, simple to learn, simple to use […]![]()
Uh-oh, Ric Phillips is back… And I do mean that as a compliment! Too often, when people ‘get it wrong’, it’s because they haven’t bothered to read the description, or to think, or both. But when someone like Ric –…
While we often find ourselves advocating for design documentation, we typically are referring to “some” design documentation vs. “more” design documentation. When it comes to design documentation, more is actually not better. We have encountered customers, and even other consulting firms, that deliver design documentation by the inch – measuring design quality horizontally across the […]
Subhead: Modernization is NOT Optional!
Once again customers of The Royal Bank of Scotland (RBS) and its subsidiaries Ulster, Natwest etc are in trouble! Unable to use their debit cards, or access their funds! And the new Chief Executive Ross McEwan admitted today that RBS has failed to invest properly in its systems for decades! RBS has given no explanation of the crash, except that it was not related to the high volumes of transactions on Cyber Monday.
Actually the root problem for RBS, and many other banks and other very large organizations, is NOT that they haven’t invested in their systems for decades. The problem is that they have allowed the systems to evolve without good architecture and governance. Banking systems in particular used to be leading edge. But over the years the core systems that actually run the bank, have become badly out of date. Instead of modernizing the core systems, many banks have responded to demand for new products and services by surrounding the old legacy systems with new bolt on systems. As a result the old systems are held together with sticky tape and sealing wax, and modified piecemeal to adjust to new requirements, and the new systems create more and more interfaces and dependencies (including duplicated, hard coded business rules), so that eventually the systems resemble a hair ball. And as you know, a hairball is a tightly packed cylinder of fur, which also includes all manner of foreign particles, which can be quite hazardous in humans and animals. In systems terms we would more usually refer to the resulting mess as a monolithic systems portfolio.
The root problem therefore is twofold:
1. The increasing complexity and risk inherent in making change.
2. Increasing horizon of any change.
And the issues become apparent either when extremely complex operational processes execute incorrectly, or when changes in process, software or environment are made, often unavoidably without full knowledge of all the implications due to lack of experience, documentation or even code!
Although I have no doubt that in all the large banks there are fierce debates about the IT budget, strangely the solution to this problem isn’t about the amount of money that needs to be spent. Rather it’s about how the organization embraces a real modernization program, which is led by good architecture and managed with strong governance.
Sadly in the IT industry the term modernization has come to mean something quite specific – the re-platforming or technology upgrade of some application. Whereas modernization should really encompass a much broader remit including:
1. Establishing a lingua franca between business and IT so that modernization issues and implications are genuinely understood by both business and IT management.
2. Defining a business systems architecture that a) facilitates transformation with low risk and b) progressively develops an inherently agile architecture, that can evolve continuously.
3. A roadmap for progressively rationalizing the business systems portfolio to comply with the architecture.
4. Implementing an integrated business and IT organization that owns the business systems.
5. Implementing knowledge management around business systems that ensures integrity and consistency and ownership of processes, information and rules.
6. Implementing a continuous Agile modernization and ongoing evolution process in both business and IT.
7. Establishing coordination, governance and risk management that ensures architectural integrity at all stages of the life cycle.
It would be easy for business management to think that the sort of problems experienced by RBS and other banks as IT problems. The above list suggests this is nonsense. The only way to properly resolve the issues is for business management to accept co-responsibility for IT. And it’s no accident that the first point in the list above is to ensure that business management understand the issues they are dealing with, and can communicate effectively with the IT organization. This isn’t just attending an education class; it’s embracing a common language that allows critical decisions to be taken on a properly balanced understanding of business and IT assumptions, costs and risks.
Retailers, manufacturers, power companies, logistics companies, government departments etc etc should not be complacent or smug when they see the problems at the banks. In fact almost all very large organizations have these problems. And the message for all enterprises is Modernization is not Optional!
Links:
RBS Crash – Management Prefer Offshoring to Modernization?
CBDI Journal Reports on Modernization