Category: Enterprise Architecture Page 1 of 3

In that perverse type of functional organisation that has a functional business unit for each profession, there is a predictable progression for each function.

The function cannot succeed until it is centralised
The function cannot succeed until it has the sponsorship of the CEO
The function cannot succeed until it has its own “Chief xxxx Officer”
The function cannot succeed until everybody understands that the function is “everybody’s responsibility”
The function cannot succeed until it has the resources to engage with “everybody”
The function cannot succeed until there is a dedicated business unit that makes the function part of the business-as-usual process
The function cannot succeed until it has input into the strategy of the organisation
The function cannot succeed until it is part of the organisation’s culture
The function cannot succeed until it reports to me

Shifting to a Data-enabled Organisation – from I.T.’s Perspective

By mdegeorge

On February 21, 2018

In Business Architecture, Capability Engineering, Data Governance, Enterprise Architecture, Information Management, IT Management, Technology-Enabled Business Transformation (TEBT)

I.T. gets a bad wrap in some information management initiatives. I prefer to take the approach that many IT disciplines are helpful for better information management. The shift from I.T.’s perspective often looks like this:

More capability-based planning goodness

By mdegeorge

On February 14, 2018

In Business Architecture, Capability Engineering, Enterprise Architecture

Good capability-based planning article: http://fia.workem.org/index.php?option=com_content&view=category&layout=blog&id=14&Itemid=111

Avoiding the B.A.I.T. view of Business Capabilities

By mdegeorge

On August 15, 2016

In Business Architecture, Capability Engineering, Enterprise Architecture

Reference material added here:

Breaking free of B.A.I.T. -based Capabilities

Getting closer to the future of the IT function

By mdegeorge

On February 9, 2016

In Business Architecture, Collaboration Architectures, Enterprise Architecture, General Management, Uncategorized

My views on business capability-based governance extend to the idea that an “IT function” doesn’t really make any sense at the highest governance levels. However, the implications of this are significant. So, in the meantime….

Customer centricity – solved

By mdegeorge

On January 30, 2014

In Enterprise Architecture, Information Management, Innovation, Technology-Enabled Business Transformation (TEBT), Thought of the day, Uncategorized

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:

The problem of customer orientatino is largely solved if you have the will to implement from matthewdegeorge

PDF: The Problem of Customer Orientation is Largely Solved – if you have the will to implement

Operating Model versus Data Governance Models

By mdegeorge

On January 20, 2014

In Enterprise Architecture, Information Management

There is a simple link between the “operating models” of the Enterprise Architecture as Strategy approach (see here) and data governance approaches (see here).

See below for the relationship:

Operating model versus data governance models

“Four operating models” slide in the centre of the above diagram is taken from here (which is taken from the book).

10 linchpin business performance improvement initiatives you should be running right now

By mdegeorge

On December 5, 2013

In Business Architecture, Capability Engineering, Collaboration Architectures, Enterprise Architecture, General Management, Innovation, Technology-Enabled Business Transformation (TEBT), Thought of the day

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

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.

Management as a service, again

By mdegeorge

On September 26, 2011

In Business Architecture, Collaboration Architectures, Enterprise Architecture, General Management, General MWT, MWT Themes

Nice:

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:
http://weblog.tetradian.com/2011/09/26/rethinking-architecture-of-mgmt/

Architecture Versus Management?

By mdegeorge

On March 1, 2011

In Business Architecture, Christoper Alexander, Enterprise Architecture, General Management, General MWT, Pendulum Argument Augmentation, Technology-Enabled Business Transformation (TEBT), Thought of the day

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.