Category: MWT Components Page 2 of 4

A16z Podcast: Engineering a Revolution at Work | Andreessen Horowitz: “today’s cloud-based tools change the role of managers”

Including this:

“Theses are the things to me that are just these huge cultural shifts in how you manage an organisation. What your role of a manager is in a meeting is no longer to be reported to. Because frankly if you want to know, you should just go to the place that everybody on the team is already using to keep track of there information. When you get everybody together it shouldn’t be to argue the pros and cons of how the information was gathered, or is it the right number, or is the number pivoted the right way. We wall agree, this is the number, is it good or bad? What should we do as an organisation to change that number?”

Given the premise of this blog, and the time I’ve spend in information management, to see the idea that technology can effect what it means to manage is always pleasing.

And this:

“It’s not that you’re going to look at a 15 page status report and say ‘how can I do a 15 page status report in this tool?” or look at this giant tracking spreadsheet and say ‘how do I do this in a tablet?’. What’s happening is new tools… The tools are now five years old, or at the very least two or three years old, and all of the sudden we’re seeing this explosion in new approaches to the work products themselves and that’s what’s particularly exciting right now… There’s enough experience with the form factor to say now we don’t just have to do it the old way.”

Analytic teams need their own IT… but should they?

By mdegeorge

On March 18, 2014

In Analytics, Capability Engineering, Collaboration Architectures, IT Management

As per linchpin project #9 (“Project 9. IT federation: shrinking corporate IT and embracing shadow IT”) we need to view our success in terms of capabilities not functions – and remove any roadblocks to maturing our capabilities.

So this is happening:

Big data: Why IT departments mustn’t be a drag on analytics | ZDNet: “‘Technology functions are still finding it difficult to keep up with business demands. Working in analytics and being responsible for analytics, I can’t let that happen,’ said RBS chief analytics officer, Customer Solutions Group, Alan Grogan.

‘I can’t turn around to my CEO or to my customers — or even just if I want to retain staff — to say ‘I’m sorry, we just don’t have the scalability, the flexibility or the control on the domain’.'”

At the same time, there are efficiencies in building a federated IT capability. When Analytics teams need to manage their own IT they aren’t evolving the IT function. And when Analytics teams manage their own IT the IT function has to evolve. There is a joint responsibility to manage this process.

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.

The end of IT alignment

By mdegeorge

On March 11, 2013

In Capability Engineering, Collaboration Architectures, General Management, IT Management, IT Outsourcing, The New MWT Hierarchy

The language of IT alignment has to end. It’s no longer serving any purpose except to isolate disciplines that no longer need to be managed in isolation.

The convergence of the commoditisation of IT and the socialisation of business means that IT in its strictest purest sense has won. Paradoxically it also makes IT completely unimportant as a competitive differentiator.

IT is available cheaply to anybody who wants it. IT can be acquired easily in packaged form, or as a service, through any number of cloud or “… as-a-service” vendors. Many would argue that this doesn’t solve all problems – but to quote the old joke about alcohol, neither does milk.

For IT systems that are not easy to acquire there are strong incentives for IT service providers and outsourcing organisations to build them. You might pay more than you’d like but that’s because it’s hard to manage these guys not because of any real scarcity.

The so-called socialisation of business is a trend that slightly trails the commoditisation of IT. In fact, the consumerisation of IT appears to drive both. While it might have once been the IT departments job to drive adoption of IT to improve efficiency this is no longer the case. IT departments are now more likely to be seen as holding back the adoption of IT.

So why does this mean the end of business and IT alignment? Because there isn’t any “business” and “IT” to align! It’s always been a misnomer. Firstly, IT’s view that there was “us” in IT with all this complexity and then there was one bug lump out there called “the business” was always a farce. “The business” was just shorthand for a generic “them” that moved and shifted like bad requirements.

On the other side there was “The business” – rich and complex and important. In “the business” there were performance incentives, real customers, governance considerations, all that important people management and cultural change, etc. But this side of the fence had some delusions too. Over the last 20-30 years much of the value that business units mentored was shifted into IT systems. But unfortunately this meant managers thought it was shifting to IT.

When I asked who is responsible for the information in the IT systems during a recent meeting everybody in the room pointed to the IT guy. When I clarified and added that I meant the real details of what the information means they still – and they always do in my experience – pointed to the IT guy.

You see somewhere along the line people started believing that if something passed through an IT system it was suddenly owned by IT. But it got even worse than that. Because these “IT alignment” problems went on for so long, and nobody ever fixed them, and because IT was the service provider and “the business” was “the customer”, the IT team compensated.

So not only did everything that pasted through an IT system become owned by IT, everything that was “detailed” became an IT problem. Let me explain. The thing with IT systems is that they persist. If you have a human system you need to teach the new humans the system so the system can continue to operate when the old humans leave. This process keeps the system alive. IT systems, except for some overworked back-end humans, don’t need this. IT systems continue to operate regardless of the passing of knowledge to new humans.

Over time this has meant that where systems are built on technology the detailed knowledge of the system are lost. Nobody knows the details of the system. However, when things went wrong somebody had to find out those details. The IT groups had the keys to the back-end of the system so were able to find out how the system worked.

Even though IT people could find out how the system worked it didn’t mean that they were the cause of the problem. Sometimes the world had changed and the system didn’t work in the new world. But at the end of a long investigation the only person who could fix the problem was the one person who had spent time looking at the details.

This process had an interesting effect on the users of IT systems. Not only did they think that things that passed through IT were now owned by IT, but they thought that “the details” were owned by IT. In fact, I think that in many contexts the term “technical” and “detailed” have become interchangeable.

I’ll skip over the process where all of the people with “technical” knowledge – including detailed knowledge of “the business” – were outsourced. That’s just progress – it’s done – get over it. But it’s an important step in the story. Because it’s now possible to acquire the IT components of your business easier they are no longer a competitive differentiator. Trouble is because the IT components still have value, and your competitors can acquire them, they are a business imperative.

To actually differentiate you have to do what you’ve always had to do, build hard-to-replicate capabilities that combine people, process, information, and technology. It’s the integration of all of these that creates value. So why all the talk of “IT Alignment” in the first place? Who knows! Growing pains?

So, What’s next?

Because IT is easy to acquire, and because business units can’t seem to manage the details of how their processes operate, and because it’s integrated capabilities that drive competitiveness, a complete governance change needs to occur. It is no longer effective or necessary to have a primary governance separation between business functions and IT.

But hang on! I could also track a whole history of cross-functional collaboration within organisations. Every single problem in every single organisation appears to be solved by “a cross-functional team” right? In fact, the whole structure of management education has become about educating future managers that a. All organisations are made up of common functions (IT, HR, Finance, etc) and b. that their job as managers is to coordinate across these functions.

This process, that builds organisations in which every collaboration of value is an exception and then creates managers who are rewarded for intervening is bullshit (!). Our governance models need to change.

The thing that needs to change first is to give people responsibility for capabilities. The end-to-end responsibility for something regardless of the separation between “the business” and IT is the very first step towards “alignment”. If you haven’t done this stop working on alignment issues until you do.

Blast from the past: “Organisational Usability”

By mdegeorge

On November 26, 2012

In General MWT, Innovation, MWT Components, MWT Themes, Thought of the day

I’ve had to delve into the Internet Archive Wayback Machine – to about 2005/6 it looks like to find an old article I wrote on “Organisational Usability”. I thought this was going to be big at the time. In fact I think it is starting to be big:

See here for original article: http://web.archive.org/web/20060507201901/http://www.managewithoutthem.com/show_article.asp?statement_id=114

…and the MWT Archive here: http://www.managewithoutthem.com/Archive-Feb-2007/MWT%20Complete%20Archive%20Feb%202007.pdf

Organisational Usability I

	Related Articles The Internet: Anti-Capitalism or Hyper-Capitalism? MWT Systems Framework Managing At, Managing Within, Managing Out…!

In the hyper-capitalism of the Internet your web site’s usability can make or break it. A bunch of competitor web sites are only a click away; so if your site is too hard to use, ‘click away’ your visitors will. If the effectiveness of your web site depends on its usability, why not use that model for your entire company?

One of the Core Concepts of ManageWithoutThem is Organisational Usability. Organisational Usability is a broad term, created specifically for the ManageWithoutThem model. We will be revisiting Organisational Usability in future articles.

Organisational Usability uses the analogy of an Internet web site for your entire organisation. It is the advent of the Internet (and other personal communication technologies) that has made apparent the need for organisational redesign – so the analogy is a good fit.

Your organisation exists as a resource to be used by your customers and your employees. That is not to say that your organisation should be left to the whim of your employees and customers. What we mean is that as your employees are serving customers or creating new value through projects, they are leveraging the resources of your company. In this sense, your customers and employees are ‘using’ your organisation.

The effectiveness and efficiency in which the resources of the organisation can be leveraged is the Organisational Usability of the organisation.

And now some examples of the Web Site analogy in action…

Link to Homepage

One of the first lessons you learn in any web site usability course is that each page should have a link to the home page. This is because users of your web site might not enter the site from your homepage. Users need a way of exploring other pages of your site and other information or services you might offer.

As you gain experience with web site development you start to realise that the ‘link to homepage’ approach is an inadequate solution to the problem of mid-site entry into a web site. In Organisational Usability this is the equivalent of having to call the CEO to get something done!

Links to Related Services

Your organisational will have high Organisational Usability if it has a more sophisticated strategy than ‘ask the CEO’ whenever somebody finds itself lost within it.

Departments, particularly shared service providers, should be aware of any services that are related to their offerings. This will include relationships up and down the value chain, as well as peer relationships. This will also include relationships outside your company. Your IT department should know about the IT industry. Your Accounting department should know about the Accounting industry. Your Procurement department should know about the Procurement industry. (etc)

Pre-emptive Processes

When somebody visits your web site you have no idea how much of their purchase they have already completed. The web site user might need background information on how to start looking for products in your industry. Alternatively, the web site user might already have a part number and their credit card ready.

The importance of this to Organisational Usability is that the customers and employees of your organisation may wish to enter your processes from a point other than the beginning.

Equally as important, your employees and customers will be of varying levels of sophistication. Some may want you to manage things for them; but others (probably the best ones) will want to manage things themselves.

Still more sophisticated, might be those that want to ‘outsource’ the activity you provide for them – with very high expectations of service and quality. It is also likely that users have entered your site through a Portal of some kind.

For these reasons your customers (or employees from other departments) may not always want your Project Management services. Your customers may want to define their relationship with your process themselves.

Process in context

Your web site might have the most easy-to-use ordering system ever created, but it is not very helpful if your customers can’t get to it from the product they wish to buy. For this reason, the practice of placing ‘Buy Me’ and ‘Go to Checkout’ buttons beside each item is well established.

As far as Organisational Usability is concerned it should be understood that the context of day-to-day business will never be your companies business management system (which lists all of your organisation’s processes) – and you don’t want it to be.

If you want employees and customers to use particular processes you should think very carefully aboutwhen they will need to use those processes. Process owners should ask themselves: What would an employee be doing at the time that they should use my process? Then, every effort should be made to make the process visible from that context.

Frames

For those that don’t know, ‘frames’ (or ‘framesets’) is the term used when building web sites to describe a page made up of multiple sub pages viewed together. Frames are often seen as poor web site design because you don’t know if you are viewing a page as a stand-along page or if you are viewing the page in the context of the rest of the frameset.

In terms of Organisational Usability frames represent the other things that your employee or customer knows when they use your processes. The fact is they may know more or less than you expect.

Markets: Employees and Customers Converge

There is constant reference to Employees and Customers within this article. The traditional view of organisations requires you to view these as fundamentally different groups. Once you start viewing your organisation from the perspective of it’s Organisational Usability your will see these two groups converge.

After all if your company’s web site really does provide useful information about your organisation your employees will also visit it regularly.

It’s not all about people – it’s about respecting people enough to make the systems work

By mdegeorge

On October 30, 2012

In Collaboration Architectures, General Management, General MWT, IT Management

How many times have you had an employee come to you with a complaint about how a process works, or how an IT system is broken, or how they aren’t getting along with another department, and you’ve basically counselled them. You’ve told them how they might get a better result if they approach the situation a different way. Maybe you’ve suggested that they escalate this to another person. Perhaps you’ve even brokered a meeting where the two groups just sit together to rebuild their relationship – just try and see it from each other’s point of view.

You take this approach because people management is important, right? You take this approach because “it’s all about people”. But don’t you think if the system wasn’t broken there would be less of these “people issues”? It’s the most respectful thing you can do for the people in your organisation to make the organisation itself work better?

That fact of the matter is that your people are not your most important asset. Your systems are your most important asset. Because when your systems work, and make it easy for your people to operate your organisation (i.e. what I call “organisational usability”) then your people will stay. Your “assets” support your customers first, and your people second. And that is all. To say your people are “assets” is actually pretty offensive.

The fast is you need good people if you want to change anything. People have ideas, people make stuff happen. But the more you are relying on people to do basic tasks, work arounds, and counselling sessions, the more you are destroying the competitiveness of your business by adding unnecessary costs to the cost structure.

The idea that you should focus on making your organisation a “great place to work” doesn’t contradict this in the slightest. Being a great place to work means the people in your organisation aren’t constantly trying to avoid being the ones who do the low value jobs. Being a “great place to work” means that management systems are in place that ensure that you don’t have to suck up to your line manager in order to be recognised for your contribution.

Constantly focusing on the people, at the exclusion of focusing on the systems, is completely counter-productive. Of course, I mean “systems” broadly, beyond IT systems. But more importantly, I mean the systems that create a set of unique capabilities controlled by your organisation and connect those capabilities to customers.

The only reason managers focus on people is that they want to manage them – read: control them. If you make everything into a people issue you don’t have to fix your partner eco-system, you don’t need to have a strategy, and you don’t need to manage risk. Or more importantly, you can focus on your own career progression rather than making the systems work for people who operate them (too cynical, perhaps?).

By focusing only on people you just get to wake up in the morning, see what’s failed and fire somebody, or ask everybody how they are adding value and let them take the effort to justify. This is the extreme but natural conclusion of how focusing on people plays out. By only focusing on people you’ll find yourself saying things like “Bob doesn’t get it” when there is no “it” to get. Like I’ve said before “management at it’s worst is the art of saying ‘you’re not seeing the big picture – even when there clearly isn’t one'”.

The more you focus on the people, and the less you focus on the systems, the more you’ll need to focus on the people. People in an untidy, unstructured, and ultimately political environment will undoubtably require more attention. People who need to end their day manually collating information and re-typing into systems that don’t work will require more attention. People who need to collaborate across teams where no agreed protocols exist will require more conflict management. People who need to suddenly “do more with less” will – by definition – actually do less with less until the systems change.

It’s time to respect people by managing systems.

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/

Business Architecture in the never-ending standardisation process of EA

By mdegeorge

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.

Game Dynamics and Internal Market Making

By mdegeorge

On August 27, 2010

In Collaboration Architectures, MWT Components, Technology-enabled Markets

I like the idea that Seth Priebatsch is ‘determined to build a game layer on top of the world’ in the same way I like Jane McGonigal’s work to save the world with games.

Seth says in his TEDxBoston talk linked above that while the last 10 years have been about ‘building the social layer… has been building this framework for connections’ the next 10 years will be about perfecting the management of the rules that get the desired outcomes from the connections – the games.

I think this is very close the market-making and collaboration architectures of the MWT Model – so I’m excited and pleased.

I also like the reference in Seth’s talk to Loyalty schemes. Basically he is saying that the rules of Loyalty schemes and airline mile programs can be redesigned into a game rather than as they are now (“that actual do use game dynamics… they are using the game layer… they just suck”).

Dan Pink: Management is a television set (i.e. technology)

By mdegeorge

On August 11, 2010

In General MWT, Operationalised Brands

From Dan Pink’s TED talk on “The Surprising Science of Motivation”:

“In the 20th century we came up with this idea of management. Management did not emanate from nature. Management is not a tree it’s a television set. Okay? – Somebody invented it. And it doesn’t mean it’s going to work forever… Traditional notions of management are great if you want compliance. But if you want engagement self-direction works better.”

Pink also introduces parts of his “new operating system for our businesses” based on autonomy, mastery, and purpose.

The specifics of Pink’s new operating system are interesting – but I think as values they are almost universally accepted. More interesting is the acknowledgment that you might install a new operating system into organisations to replace ‘management’ itself. This idea has been the premise of MWT from its inception (see here and here for example).

The general principle of the MWT Model is to replace planning, monitoring, and controlling with collaboration architectures, technology-enabled markets, and operationalised brands. The MWT Model also positions management as a technology rather than a class of individuals.

In a sense, Pink’s new operating model fits into the MWT Model by acknowledging management as a technology, replacing it with something else, and operationalising an internal brand based on the values of autonomy, mastery, and purpose.

Awesome!

Watch the full video below:

;