Monthly Archives: February 2011

Where to start?

The Developer: “Let’s start coding. We don’t have time for solution design.”

The Designer: “No, we should design first. It’s not a waste of time. It will reduce rework.”

The Analyst: “Guys, please! How to start designing, if we don’t know what the problem to be solved is?”

The Tool-lover: “But how to diagnose the problem without a tool? Let’s choose the tool first.”

The Architect: “Yes, but to choose a tool, we first need to make sense of the context and only when we know where we are, we can have criteria for choosing the right tool.”

The Tool-lover: “Doesn’t that mean we need a sense-making tool? Again, as I told you, we need a tool first.”

The Analyst: “No, this just means that we have to first analyse the context of the context. Let’s focus on that.”

The Developer: “20 lines of code ready while you are discussing.”

The Designer: “That’s a waste of time. But you, developers, don’t have a sense of time anyway.”

The Architect: “Time is an interesting thing. Good you mentioned it.”

The Analyst: “Is ‘time’ the problem?”

The Tool-lover: “We probably need a stopwatch.”

The Architect: “What we rather need is to stop and watch.”

… and so on.

Integration of strategic, project and process KPIs

Some organisations, after straggling to implement Balanced Scorecard Systems (BSC), come to the conclusion that they need to at least map their processes. But then the challenge they face is how to link strategic with process KPIs. Others are practising some sort of BPM but have difficulties demonstrating its contribution to the bottom line. As Anatoly Belychook recently wrote:

business consultants know what should be done eventually but have vague understanding of how strategic goals can be achieved with the help of BPM

There are many ways to do that. One of them, usable in the ‘ordered’ domains, is to include process KPIs in the formula of certain KPI (or ‘KGI’, to conform CobiT’s terminology) of a strategic goal. It’s simple but not so straightforward so let’s first have the bigger picture.

There are basically three types of things in the motivational domain: goals, means and influencers. (If you need to dig deeper, Nick Malik’s EBMM is a good place for that. Interestingly, one of the things that had driven that extension to the BMM was the work of Alexander Osterwalder, one of the authors of the now popular Business Model Generation book) The means to achieve most ends, especially of those belonging to the classic ‘process’ perspective of the BSC, either require certain change to be managed or some parameter(s) to be kept within desirable range or both. Let’s illustrate this by combining it in a single case where a strategic goal is supported by certain process which is no yet implemented. Thus there will be another ‘means’ representing the project to implement that process.

KPIs are either primary or derived. In the example, the strategic goal is measured by a KPI 1 (derived) which is calculated by the value of KPI 1.1 (primary), KPI 1.2 (derived) and some specific attribute of their relations like weighting for example. KPI 1.2 is calculated from the values of the project KPI 1.2.1 and the process KPI 1.2.2. They are in reality more than one for both project and process management. If the project duration is shorter than the control frequency  of the strategic goal, then for ‘period 1’ KPI 1.2 will take KPI 1.2.1 and KPI 1.2.2 value times their respective weighting. For ‘period 2’ KPI 1.2.1 will be equal to the value of KPI 1.2.2.

Such an approach needs the support of a repository based tool for modelling and analysis. No matter if its primary focus is EA or BPM, it should support enterprise motivational domain and ideally project and program management.

Patterns of Informal Architecture

The CEO was referred to as ‘the architect of the enterprise’ long before ‘Enterprise Architecture’ was coined. The ‘architect’ metaphor was used in 60s and 70s and became quite present in the strategy management literature of the early 80s. And indeed, big part of the job of C-level executives is to manage (different domains of) the architecture of the enterprise. That part  is not labelled ‘enterprise architecture’ and probably shouldn’t be. But it must be recognised as such by the ‘formal’ Enterprise Architects. If formal enterprise architecture finds a way to play together with the informal one, this in turn would help the latter understand how to get more benefits from the former.

One way is to use less formal techniques to explain formal EA to the C-level and other practitioners of the informal EA. Storytelling looks like a good way to do that. Another way is to show how formal and informal can go hand by hand and best do it again in a story, the way Chris Potts did in ‘recrEAtion’. Yet a third way is to make it a habit for formal EA practitioners to recognise patterns of informal EA.

It’s not difficult to spot them in processes and cases such as creating/changing chart of accounts or profit/cost centre structure or product/service portfolio. (Or, is it?) Informal EA patterns are also easy to find in any standardization effort or planning a new business capability, opening a new branch or running an integration program after a merger. It’s easy because all those cases have some kind of formalisation, albeit not an EA one. That’s not the case with patterns of informal EA in people relations. But the effort is worth it. Relations between people are of primary importance both for the enterprise and for managing its architecture. This week it was the topic of some very good posts by Tom Graves and Nick Gall. So here, another touch in the context of informal EA.

Formal EA uses models a lot. All models represent certain aspects of the past or the future. (I put ‘as-is’ models in the ‘past’ category as well.) Models of people relations are no exception. Models of the past relations are basically two types: some are based on perceptions and decisions of the modeller about certain aspects of reality and others are visualisation of actual characteristics, registered using some technology:

All models, actual and perceived, belong to the formal EA tool-kit. If we superimpose the two pictures above, conceptual, logical and physical would go to the two ‘perceived’ quadrants, and ‘operational’ – to the ‘actual’ one. What is left is the ‘informal’ relations. They are relations, therefore fall in the EA domain. They work and could be very powerful, therefore are important. Moreover, they are adaptable and can easily cheat the formal one. Here’s an example:

Bill starts a new project and needs a team leader for one of the teams. He has to fill in a request form and send it to the HR Department. Then hope they could come up with the right person from the huge database of employees. Bill doesn’t want to leave things to chance. He calls his colleague and friend Kim and asks him if he knows somebody that has capabilities as that team leader, remember, from the project A which they were involved together last year, but at the same time can handle situations of the type they had three years ago and has that and that technical experience. And he/she should be available for the project period as far as Kim is informed. Kim doesn’t know such a person available but he knows Sarah. Sarah is in a different location. They never worked together but Kim trusts her and has reasons to believe she might be able to help. After a few hours Kim sends Bill a message with the CV of a person recommended by Sarah. Bill gets some specifics of the CV and sends them as requirements to the HR department.

Some may argue that this story is about Knowledge Management, not EA. I agree it’s KM and disagree that it’s not EA. It certainly is and belongs to the grey cloud in the picture above.