Reference material added here:
Category: Enterprise Architecture (Page 1 of 2)
I just found a nice overview diagram (nice in content, not in style) where I thought I’d solved the problem of creating a customer-centric organisation just by breaking the challenge into its components.
It’s a year or so old but to be honest it still looks about right:
See below for the relationship:
It’s often difficult to understand how your portfolio of projects is actually helping your organisation deliver to its strategic goals. The problem is that the projects in the portfolio often don’t play a part in ensuring the overall portfolio is easy to navigate and cohesive. You need linchpin projects in your portfolio to hold the others together.
Linchpin projects are different to other projects in the portfolio. Linchpin projects don’t have a business case in the traditional sense – because they are strategically placed into the portfolio to hold it together, identify risks across the portfolio, and steer cross-project decision-making.
Linchpin projects are value-seeking initiatives that raise the value of the entire portfolio. In fact, linchpin projects represent the new normal for combining operations and program management in the digital economy.
Your current portfolio
Your current project portfolio is probably made up of three types of projects:
- That subset of projects that had a strong enough business case to make the cut at the expense of other projects
- Projects that your organisation almost left too late, so are now critical – or projects that unanticipated changes in your operating environment have recently made critical, urgent, or “must haves”
- Big, chunky, game-changing programs that have been initiated following a strategic analysis & planning process. These are often more of a top-down prioritisation of investment rather than a fully formed project, until a more comprehensive analysis of the full impacts is performed
The decisions that initiated each of these projects aren’t always perfect. But you have no choice but to plunge ahead with the projects. However, each of these types of projects presents challenges to the management of your portfolio as a whole:
- You selected some projects at the expensive of others – but when and which of those forgone projects will become your next critical projects?
- Critical projects that have now become urgent will need to take shortcuts – but what ensures these projects understand the shortcuts that are available, or to plan the follow-on work required when the projects are complete?
- Strategic projects represent investment priorities which will have the greatest impact on your customers, asset utilisation, and business performance – but how do you incorporate the best knowledge you have of what influences these into the strategic project’s planning and execution? (Without putting all other projects on hold!)
Major projects versus linchpin projects
It’s a mistake to think of your major projects, or your strategic projects, as your linchpin projects. Major projects are often run as exceptions, so the transformational impact of these projects is often limited or followed by organisational fatigue or regression. Linchpin projects on the other hand inject specialised disciplines into the portfolio and in many cases don’t need to be large investments.
However, there is an opportunity for your major strategic programs to host a number of linchpin projects to get them started. The trick is knowing which linchpin projects you need…
Which linchpin projects do you need?
Regardless of your organisation, the following linchpin projects should be in your portfolio. The characteristics of your organisation and current strategic direction will only impact the size and approach for each of these initiatives.
Project 1. Business capability based governance
Our organisations shouldn’t have a primary governance model that divides the organisation into functions and then constantly proliferates the need for cross-functional teams. Social enterprises don’t require this approach – so your organisation’s primary governance should be mapped to business capabilities, not functions. This is also the first step in ensuring “business/IT alignment” – by stripping back the historic and arbitrary separation that is the root cause of misalignment.
Project 2. Customer journey design & customer experience campaigns
If you can’t point to artefacts which describe an idealised view of how your customers experience your organisation, then you haven’t done enough thinking about your customers – and you have nothing to orient your organisation towards customer outcomes. Equally, if you can’t point to specific customer-facing processes, technologies, and metrics that continuously direct the resources of your organisation towards reenforcing positive customer experience and recovering bad customer experience – then your customer journey design is just sitting on a shelf!
Project 3. Asset life-cycle, utilisation, yield, and pricing
Airlines, hotel chains, mining companies, and farmers understand yield. They understand that large expensive assets must be effectively carved up to service the right customers, at the right time, and for the right price. In the digital economy this same process must be applied to every organisation’s assets. If you don’t understand the utilisation on your major assets, and how projects can impact this, then you are running a business that provides a higher cost product – or your are running a unsustainable business.
Project 4. Core shared data strategy, information asset governance, and decommissioning
Unmanaged, the information in your organisation can get out of control. We have access to so much technology – information technology – that is supposed to help us manage information. So why are there so many copies of the same documents? Why can’t we rely on information we receive from other departments? And what is cut-and-paste if not investment in the problem instead of the solution? The solution is to systematically discover and invest in information assets across their end-to-end lifecycle – focusing in particular on the “core shared data” that is key to coordination across business units. Oh, and don’t forget you can’t ever throw data away unless you know what it’s worth (i.e. Business value) – but some data you can’t afford to keep (i.e. Privacy Act).
Project 5. Combined process, information, and user forums – fit-for-purpose scorecards
Your employees know what is wrong. But there are few mechanisms for feeding that learning into operational improvement initiatives. Lean and Six Sigma ™ come to mind – but that’s just details. Whenever your process team talks to people who should be following processes – capture the reasons why they’re not! Whenever you find yourself questioning a decision an employee has made – capture the missing information that caused the wrong decision to be made! Whenever somebody throws their keyboard across the room – ask them why! Better still – combine all of this into a single session which uncovers what is wrong around this place.
Project 6. Innovation funnel, lean business case, and start-up support
Innovation, or rather an entrepreneurial culture, starts with hiring entrepreneurs. But what if you can’t keep them? There are three reasons you can’t keep them: 1. You don’t recognise the good ones – because you don’t have an innovation funnel. 2. You frustrate them – because there are too many barriers to implementing business cases for change. 3. They can get better, cheaper start-up support in the market. These things are easy to fix and can be funded to the extent that you value innovation.
Project 7. Voice-of-the-customer operational alignment – Customer Return on Operations
It’s pretty easy to gather basic voice-of-the-customer data. For example, you can just asked the simple “How likely are you to recommend us to your friends? And why?” questions at the heart of Net Promotor Score (NPS). The hard part is doing something about it. You need to systematically determine what parts of your operations have the most impact on your customers. Management of “customer return on assets” will tell you most of what you need to know about how your projects are impacting your performance – from your customer’s perspective.
Project 8. Competency centres and change levers – The Machinery of Business Transformation
There are two ways to transform your organisation: you could run a heavy transformation program, and then an even heavier organisational change management initiative – and hope you get both right. Alternatively, you can manage to a transformation agenda – vision – and a portfolio of integrated competency centres – collaboration and continuous improvement towards that vision. If you know your own organisation’s portfolio of competency centres, their service catalogs, their customers, and the most effective channels and levers of change for your particular organisation, then implementing your whole project portfolio, and avoiding unintended consequences, becomes much easier.
Project 9. IT federation: shrinking corporate IT and embracing shadow IT
Even with your primary governance now focused on business capabilities (see Project 1) you still need to manage IT. But the difference is you need to manage all IT, in the only way you can in a post-Cloud, outsourced, and BYO world – federated IT. Learn to manage IT without ignoring what is out of your control and you’ll revolutionise productivity within your organisation while spending less than you did on IT services, architecture compliance, and generally inconveniencing your stakeholders by trying to be the cost and standardisation tzar.
Project 10. Who are we: purpose, culture, communications, and performance
Engage, decide, communicate. There is always another opportunity to reinforce what makes your organisation unique. There are ways of doing this that improve performance. Try them.
If everything is a service, why should management be assigned any priority over anything else?
Short answer: no valid reason at all – from a services-perspective, anyway. It’s just another service, or set of services.
The only feasible reason why management might be assigned arbitrary priority over other services is from left-over delusions about ‘rights of control’. For the most part, these delusions arise from an unfortunate coincidence of functions within the ‘management-services’:
services for strategic-assessment – potentially giving the delusion that ‘knowing more about big-picture’ inherently means ‘responsibility to tell others what to do’
services for coordination of resource-allocation – potentially giving the delusion of authority over others via ‘right to withhold’, in turn arising from delusions about the (dys)functional role of purported ‘rights of possession’ within the broader society, and hence within an organisation’s economic model.
In short, architecturally speaking, this is not a defensible reason for priority. Every service is ‘just another service’ that is required for enterprise viability: hence no service can be said to have inherent priority over any other.
read it all here:
I’m increasingly seeing the management and architecture disciplines as being in a race to control organisations. Both groups show behaviours that suggest they are trying to extend their own discipline to encompass more of the organisation. Equally, both groups work hard to exclude areas they are not comfortable with from their responsibilities. Architects want to control the organisation by controlling knowledge of the structure and value streams at all levels, while avoiding execution issues. The management profession wants to control the organisation by controlling resources, while avoiding responsibility for technical issues.
Both the architecture and the management professions reveal their desires to control the organisation by the manner in which they grow the scope of their approach through ever increasing extensions of their disciplines. The management discipline has grown from supervision, to general management, to strategic management, to change management, and to all of the business unit focused sub-disciplines that form the structure of a management degree (finance, HR, etc). Conversely, architecture has grown from a technical discipline to include information architecture, solution architecture, business architecture, and information architecture.
Christopher Alexander popularised – if his ideas can be considered popular – the idea of generative sequences. In essence, a generative sequence is the process of taking a structure and changing it through a series of structure preserving transformations. After each transformation the whole structure is then evaluated to determine if the transformation has – more or less subjectively – improved the structure. This process is repeated. Alexander also defines the so-called structure preserving transformations that are applicable at each step.
This is an interesting analogy to decision making in organisations. Each time a decision is made the structure of the organisation changes. Structure in this case may refer to anything: including the attitude of an individual team-member, the next task to focus on, or even quite literally a change in the organisation’s structure as we usually use that term.
What is interesting is that from both the manager’s point of view and the architect’s point of view the details of that structural transformation are only selectively considered. Because managers are generally outcome focused, each transformation or decision is evaluated based on its perceived contribution to outcomes. These outcomes may be long or short-term, or they might be project-focused, or they might relate to the entire organisation – but it’s the outcome that’s important.
While management is primarily concerned with outcomes, the architect is concerned with structure as a whole. When decisions are made they not only impact the progress towards goals but they may also potentially impact other structural elements of the organisation. Rather than a distinction between long or short-term time horizons, or between technical and business domains, the distinction between architecting and managing is generally about outcomes versus structure.
Currently, it’s difficult for architects to evaluate the impact of a transformation in terms of the progress towards desired outcomes because a comprehensive view of the desired outcomes is rarely shared, documented, or linked to the structural elements as defined by the architect. Similarly, it is difficult for a manager to utilise the models created by the architect to make decisions because the models which describe the structure use technical language and contain much that is irrelevant to decision making.
This battle is not yet won, of course. To be a successful architect you must manage carefully, and to be a successful manager you most certainly need to be an architect of sorts. The MWT Model is driven from the theory that this battle will and is ultimately changing the practice of management itself. This may be seen as victory going to the architects but is more likely to mean that successful architects will no longer be able to choose what issues they avoid.
While this might be interesting to professionals on both sides of the battle I’m just as interested in how important this is to the organisations that we work in. As I’ve said before, I believe good IT is structural – when you implement an HR system that enables you to re-deploy some employees in the HR branch of the org chart, you should really hang that HR capability embedded in the IT system in their place.
As these structural IT changes are increasingly differentiating organisations and brokering their relationships with customers it is ever more important that organisations can effectively operate and enhance these technology-enabled capabilities. Both managers and architects currently struggle to achieve this and in the organisation of the future (now?) it’s really the only game.
This is a draft article entitled “Building an Effective Business Architecture and Metrics Capability”.
At the risk of being controversial, I don’t believe enterprise architecture is about “alignment between IT and the business”. While there is not doubt that an effective enterprise architecture practice will improve this sort of alignment, it needs to do more than improve the standing of IT or the percentage of the value pie that IT gets credit for.
Enterprise architecture is a process. But it’s not a process of creating as-is architectures, creating to-be architectures, and then creating transition roadmaps. These are useful deliverables and will indeed be produced – but they are no more enterprise architecture than a MS-Project plan is project management.
The process of enterprise architecture is about identifying the activities, information, or assets that you want to standardise and then managing the level of standardisation actually achieved. It’s also important to note that this process occurs regardless of whether or not the process is called enterprise architecture.
If you look for it, this generic process of standardisation is everywhere. Even the idea that organisations have ‘products’ and ‘services’ is a form of this standardisation. It doesn’t require an enterprise architect to see how it would be beneficial to have some standard definition of what you do for your customers.
Another example is in the familiar department structures we see in most organisations: HR, finance, IT, etc. It has been determined in the past – and may well still be true – that it makes sense to standardise how, for example, payroll is processed. So you have a payroll department rather than all business units separately designing payroll processes. It also makes sense that you’d want to standardise the way products are matched with customers. Although increasingly separate strategies in the information age, this standardisation is traditionally achieved in this case by centralising these activities into a marketing department.
This standardisation in department groupings helps to align each organisation’s capabilities with the dynamics of the labor market. It also promotes efficiencies through specialisation and definition of labour. It may not always be the case, but this generic continuous process of standardisation has created these particular groupings because there is value in standardisation in these areas.
Information technology – in the general broad sense that includes processes and methods, but also in common usage as technical I.T. Information Technology – also plays a role in this standardisation process. To use the payroll department as an example again, it is not uncommon to implement the end-to-end payroll processes beyond what is performed by the payroll department into an ERP package such as those provided by SAP, Oracle, JD Edwards, etc. This is a process of standardisation.
The real value of enterprise architecture is recursive and somewhat tautological. Enterprise architecture is a standardisation of the process of standardisation. It is an attempt at defining how this on-going process of standardisation can be managed. It’s not perfect, but it’s all we have as a method of managing this process of standardisation with any formality or openness.
Enterprise architecture as an overall integrated framework helps to standardise by providing standard categorisations, definitions, and layers in which standardisation can be achieved. For example, Technical layers allow for standardisation of platforms, infrastructure, etc. Whereas Application layers provide opportunities to standardise integration approaches, services, types of common application functionality, etc. At the Information layer it is standardisation of the definitions of information items that are important so enterprise architecture frameworks assist with that.
In all cases above, the benefits of effective standardisation include reduced costs, increased agility, reduced risks, and an increased capacity for innovation. The special challenge of the Business architecture layer is twofold. Firstly, it provides context for the other layers. Particularly for information and application layer standardisation, it is the only way to understand ‘effective’ standardisation of those other layers. Secondly, the business architecture needs to identify the areas where investment [in standardisation] will deliver the greatest value.
When is comes to business architecture the standardisation process revolves around ‘capabilities’. Remember, organisations will keep on operating regardless of what the enterprise architecture team does. So capabilities may be existing areas where investments can be made, or potential areas based on analysis of the organisation’s customers, strategies, and other capabilities.
Not all capabilities are equal, and the types and degree of benefits that can be obtained through investment will different. However, if you don’t know what your capabilities are then you can’t make decisions about which to focus on and which to ignore. The next blog entry will focus on business capability mapping and how it forms the core of the enterprise architecture effort.
There are two important themes in the MWT Model that are used to shift organisational habits. These are ‘pendulum arguments & something else’ and ‘ideal realised strategies’. Pendulum arguments are issues like the ‘centralise or decentralise’ debate that cause organisations to continuously cycle through organisational design or financial control models. These pendulums must be fixed with ‘something else’ – such as an operating model or a collaboration architecture in this case.
Ideal Realised Strategies are a separate category. These are the problems when a strategy is proposed or in place that only delivers an acceptable balance of benefits and risk if it is implemented perfectly (which of course number happens). In the context of the MWT Model, these are usually management strategies such as ‘ensure you confirm that you have closed all issues by the milestone date’.
Ideal Realised Strategies often have unstated dependancies or are otherwise unfeasible. Ideal Realised Strategies also tend to keep people in positions of power because they need to be continuously funded and supported while the strategy endlessly edges towards perfect implementation.
As I spend some time thinking about enterprise architecture I’m starting to see the whole practice of enterprise architecture as an Ideal Realised Strategy. I was also struck by title of this article (“What to enterprise architecture and socialism have in common”) and as a Mises-head of sorts didn’t like the comparison.
I usually place enterprise architecture (EA) as the anti-thisis of the overtly political approach to organisational design and decision making inherent in the managerial approach. But not everybody places EA in this context, and it sometimes appears that as EA ‘matures’ to prescribe governance and business architecture approaches it is increasingly making its success dependant on more total control of the organisation.
Any strategy that has its success based on increasingly total control of the organisation that it supports is by definition an Ideal Realised Strategy.
Once I see EA this way I can’t help but think that it’s also evolving into a form of technocracy in the same way I have argued that managerialism is technocratic. It also risks becoming part of a pendulum argument in the way I have seen organisations swing from sales lead (“if we don’t sell anything it doesn’t matter what we deliver”) to delivery lead (“if our delivery suffers our clients won’t want to buy our product no matter how good our sales people are”).
EA is changing – needs to change – but let’s get this right.
Update: there are some nice hints towards an EA approach less obsessed with centralised power in the Gartner press release I’ve previously referenced.