Category: Business Architecture

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

By

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

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

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.

 

Business Architecture in the never-ending standardisation process of EA

By

On October 26, 2010

In Business Architecture, Collaboration Architectures, Enterprise Architecture, IT Management

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.

 

 

What, if anything, is a business architect?

By

On July 26, 2010

In Business Architecture

It’s time to add a new topic to this blog – business architecture.  This topic will explore trends in business architecture and how the discipline of business architecture can improve the quality of IT planning, governance, and technology-enabled business transformation programs.

The question is: what is a business architect and where does the business architecture discipline fit in the context or IT architecture?  Or is that the wrong question, and could it actually be entirely the worst place to start?

Over the last 40 years information technologies have been radically integrated into business processes and business models.  At the same time, the relatively new discipline of software development has evolved and matured in order to keep up with the capacity, quality, agility, and speed-to-market improvements that business’s dependence on IT has demanded.

As these two trends collide, the importance of the software development discipline to the average organisation has peaked.  Pure software development, no longer a core competency of the average organisation, is now a commodity.  The paradox is that while software development is now a commodity the need to integrate information technology into business models is more important, and more difficult than ever.  Add to this the oft-sighted failure rates of large corporate IT projects and it could be said that while software development is a commodity, successful software development is scarce resource!  Less cynically, the real lesson that has been learnt is that successful software development is only possible within the context of a clear understanding of the business needs that drive the software development effort and the business changes that are implemented alongside the development effort.

Software development has been commoditized precisely because successful software development, and a successful IT function, must be managed within an overarching continuum of service-based management disciplines, outsourcing contracts, technology-enabled business transformation programs, and business knowledge.

So the history of the last 40 years of the IT industry has been to learn that successful business IT requires an understanding of the business.  Unfortunately, this can be as a profound a lesson as it is practically meaningless.  It’s like learning that a hand must fit a glove or that a successful puddle is made when the water exactly aligns with a hole in the ground.  This is why there are still failed projects and there are very few artifacts being developed that formally describe businesses – even when they are sorely needed.  Practical solutions aside, the lesson is in theory very simple – in order to take the risk out of IT success you need to understand the business with as much of a formal framework as you understand other parts of the solution – you need a business architecture.

It’s a natural question to follow that if you need a business architecture then you need a business architect.  After all, you develop a solution architecture by employing a solution architect.  But if we look for business architects we will simultaneously find them everywhere and nowhere.  Very few professionals with the title of business architect live up to the promise of that name.  Yet there are many who inspire us with business architect skills.  These are the business founders, the innovators of new business models, the entrepreneurs, the so-called leaders who went that one step further and created an enduring legacy in the organisation or the cause that they created.

In short, business architects are hard to find if you look in the wrong place.   You wont find a business architect if you look at your IT team or if you look at a team of architects.  Business architects are more likely to be found architecting businesses.  The only issue may be that those architects may not be sharing in a systematic way.  We must take the step of turning the successes of these people into systematic success.

We may think that business architecture belongs at the pinnacle of IT architecture because business architecture has long been an aspirational end game for IT architects.  Conceptually, business architecture is at the top of the pyramid because we’ve built a model of IT architecture that places it at the top.  In fact, if business architecture isn’t at the top of the IT architecture pyramid then the whole model breaks – and perhaps it must break.

As the software development discipline has evolved the value of the architect skill set has been continuously reconfigured and applied to more business critical domains.  While ‘system architecture’ originally might have referred to the physical systems present in microchip and motherboard design, the architecture skill set was then quickly applied to software domains.  From there it further expanded and segmented into integration architectures, platform architectures, and application architectures.  The term system architecture was then co-opted to include multiple software components – expanded again to integrate the software components and the hardware components because they make up the entire system.  This expansion and segmentation continued.  The software and hardware architectures were combined to become the ‘solution architecture’.  But the ‘solution’ wasn’t just hardware and software so the term ‘solution architecture’ was refined again to encompass the context of what was now the technical solution as well as the business process change, financial modeling, and partnerships that supported the solution.

This continuous expansion and segmentation is as complex a history of a profession as you can imagine and it’s been played out over a relatively short period of time.  The debate on the exact definitions of various types of architectures will likely continue.  But right at the top is business architect.  Unfortunately, this leaves the most important level of analysis and specialization of the architecture discipline sitting precariously on top of a towering bundle of seemingly never-ending debates about architecture artifact, views, meta-models, and architecture governance.

Business architecture is seen as the shining gold at the top of an overall architecture framework.  This is not the place for it.  Those foundations are weak, contain much that is irrelevant, and form an historic edifice that must be climbed with each discussion – losing many travelers on the way.

It’s time for business architecture to stand on its own.  Its value is potentially greater without the supporting infrastructure that has built up below it.  In fact, it’s likely that it’s not even the right foundations for business architecture.  It’s likely that business architecture has a closer relationship with economics and politics than it will ever have with IT architectures.  There is much to learn from business architecture as a type of architecture but never as a type of IT architecture.

People are using business architecture when they are analyzing the dynamics of an existing or imagined business.  But they are likely not to be designated with the role of a business architect.  They are more likely to be planning a large-scale business transformation program, or running a business, or managing risks.  They might also be advising on the same processes – based on both deep experience and deep thinking about organisations.  But even those advisors are also unlikely to want to be called a business architect.

So this blog will be an exploration of business architecture as it standards alone – not built on the foundations of information technology or IT architecture disciplines (but often alongside the application of technology to business), nor will it assume there is a specialised business architect role built into the discussion.

This is a blog about the nature of businesses and the why they create value.  It is also a blog about how this process needs to be understood by multi-disciplinary teams trying to understand, build, operate, or change businesses.  I’ve started by throwing out the misconception that business architecture is part of IT architecture – but we also need to go one step further and build a body of knowledge which doesn’t assume there is a role of a business architect who may or may not exist.  So… Where do we go from here?

Note: the title of this post is from a booked call “What, if anything, is an architect?” (http://catalogue.nla.gov.au/Record/1115632).  Image credits:

http://venturebeat.com/2010/04/22/microsoft-joins-with-dell-to-tackle-e-waste-on-earth-day/e-waste/ and http://internetsiao.com/the-gold-bar-doorstop/.

Page 2 of 2

Previous

Powered by WordPress & Theme by Anders Norén