One year with #TheArtOfEnterpriseArchitecture

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 […]

The Inversion of Big Data

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. […]

TOGAF ADM as a coaching compass

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.

image

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.

Categories Uncategorized

Businesses Banking on Breakthrough Innovation

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 […]

Why settle for anything less than the truth?

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…

Categories Uncategorized

The Business Capability Manager

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 […]

Prose: Great for Novels, Lousy for Solution Design

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 […]

Systems Failure at RBS – Again

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