Author: mdegeorge Page 20 of 21

Matthew De George is a well respected management consultant focused on technology-enabled business transformation. He typically wont tell you what your strategy should be. But he'll "get it", and he'll help you execute. Matthew brings 20 years of experience in transforming business and customer-facing processes through the effective implementation of technology and information management practices.

TRIZ as a pattern language for problem solving

By mdegeorge

On February 7, 2009

In Christoper Alexander, General MWT, Personal

After watching Merlin Mann talking about the idea of creativity patterns today, I started reading through volume 16 of Make magazine. On page 57 there is a brief but interesting article about TRIZ.

TRIZ is an evolving set of patterns for problem solving which was first developed in 1946 by Russian Genrich Altshuller. It doesn’t appear to be fully available on-line. In fact, it doesn’t appear to be fully developed into a single definitive framework at all. Nevertheless it appears to have some interesting things to say about problem solving.

From the Make magazine article:

…Altshuller observed that the same problem types appeared time and time again, and yielded to corresponding generic solutions…

This echos with what Merlin was saying about creativity patterns in his Macworld talk. But how is this different to just knowledge? It isn’t, I guess, but these sort of endeavors open up the scope of what we believe it is possible to have organised knowledge about. They also standardise how knowledge is organised. Standardisation is important (in the sense that it allows efficient communication).

The essence of the TRIZ system appears to be utilising a number of patterns of interventions into a system in order to remove a constraint (or ‘Contradiction’) without compromising the system. To me this feels similar to the generative sequence approach of Christopher Alexander.

Alexander’s generative sequences unfold using a standard set of interventions into structure (which is system-like, I guess). Also, when the intervention is made you effectively check for ‘compromise’ when you re-evaluate the degree of life / wholeness in the resulting structure before moving on.

This idea of removing ‘contradictions’ in TRIZ also has echos of all that Ayn Rand ‘check your premises‘ talk.

Interestingly, I have always found the idea that contradictions don’t exist as very helpful in problem solving. Basically, I see them as a signal to break something up into smaller and / or different parts. I see disagreements between people as similar types of problems – and the breaking down of concepts into more elementary components usually means agreement can be found.

Of course, it doesn’t really matter if contradictions do or do not exist – the question is whether acting as-if they don’t exist is a useful problem solving tool. And I think it is.

So, patterns can help problem solving. And patterns are a ‘just‘ a way of organising knowledge. And problem solving is about making system or structure interventions and then making sure you haven’t destroyed the integrity of the whole.

Management of knowledge work is a lot like problem solving. So it’s likely to be pattern-based too. MWT Collaboration Architectures are patterns…

Merlin Mann discovers Christopher Alexander, stops procrastinating, and fumbles a little

By mdegeorge

On February 7, 2009

In Christoper Alexander

Merlin Mann stops talking about productivity and starts thinking about creativity. I’ve always had the nagging feeling that the GTD 43Folders clan were all really just procrastinating. He’s also discovered Christopher Alexander.

Does the enterprise architecture really ‘contain’ the organisation?

By mdegeorge

On January 29, 2009

In Collaboration Architectures, Enterprise Architecture, Technology-enabled Markets

Is the enterprise architecture a town plan? I’m not sure I agree with the idea that the enterprise architecture is analogous to a town plan. For example, under the work-in-progress ‘Coherent Enterprise Archiecture’ (CEA) e-book maintained here, the follow definition applies:

“The CEA strategy [is to] to lay out the Notional and holistic enterprise master plan at the high level, establish the common foundation and building blocks at the low level. The high level master plan serve[s] as the master [guideline] similar to a city plan for a city for holistic consideration. The low level common foundation and building blocks enable agility and simplicity. “

This idea of a ‘master plan’ leads the discussion into teritory best avoided. It is at odds with the MWT Model in that it is planning rather than market/architecture focused It implies that development of the enterprise architecture is a planning process that might result in a plan that should be executed.

Where the town planning analogy is helpful is in zoning. In this respect the town plan is useful in that it enables decisions. The enterprise architecture, rather than containing the organisation, enables decisions about the organisation to be made.

It also allows for anybody to raise an exception by means of identifying the a zoning law is being broken. Not only that but it’s the basis for configuration management for the town because making changes to the town will require various notices to be posted depending on zone that relates to the proposed change.

You can see other parts of the CEA framework address Buy In (http://www.liteea.com/lea.php?catid=298&blogid=1). This seems to imply that somebody else is deciding an enterprise architecture presenting it for approval. This isn’t really the purpose of EA. The purpose of EA is to allow joint decision making at the executive level.

An ‘architecture’ under MWT definition is a deliniated shared understanding. A collaboration architecture is a delinitaed shared understanding specifically for collaboration. In the case of enterprise architecture, this is collaboration during the executive decsion making processes on business process sharing and/or standardisation and data sharing and/or standardisation (which in today’s world tends to be technology spend and TEBT (http://www.managewithoutthem.com/tebt).

I’m not picking on CEA here. I think it’s well thought out and it represents a very useful ontology providing terms of reference talking about enterprise architecture. However, as I’ve said before an ontology is not a management process in itself. More importantly, the process of execution is likely to not be isomophic to the solution under development. The process is in fact likely to look conceptually like the opposite of the solution.

So while the CEA material (again, referenced here http://www.liteea.com/lea.php?catid=135&blogid=1?) effectively shows a hierachy of ‘master plan’, ‘segement architecture’, ‘solution architecture’, and ‘building blocks’ these are trying to build a picture the enterprise which fits together. Which is interesting, important, and certainly descriptive of the enterprise – but is it the enterprise architecture?

Specifically, regarding the idea of a ‘segment architecture’ I’ve seen discussion (such as here http://it.toolbox.com/blogs/lea-blog/what-is-segment-architecture-25945) which describes the rational as:

… EA [utilises a] segment architecture approach rather than the traditional big bang effort. It is a divide and conquers approach to enable incremental and continuous enterprise architecture effort based on business owners need.

This approach may be in fact become nessecary for the same reasons I’m coming to which relate to people trying to do to much in the descriptive aspects of EA and not enough in the aspects relating to the enabling of collaborative decision making. But it doesn’t tell me what enterprise architecture actual is – it only narrows the scope you are applying the definition to.

So the history of how we view EA has determine that we need to break it up into segment architectures; but the fact remains that a segment architecture is not an enterprise architecture. More importantly one particular organisation I work with takes it’s segmentation strategy very seriously – having spent considerable time aligning financial treatments to segment boundaries to allow segment level reporting of financial data. This organisation would require both segement architectures to allow decision making at a segment level and also a true enterprise architecture (not simply the sum of the segments) to enable discussions around the unification of value across segments and to reduce the risk of segment based performance optimisation at the expense of enterprise performance optimisation.

In recent communications to this particular client I have tried to raise the point that the conversations about how to apply the financial rules during the transition to segmentation have created value but that unless these conversations continue via the mechanism of enterprise architecture (not segment architecture) there is a risk that value will be los through independant optimisation of performance of the type described above (at the segment level).

Where is platform architecture?

If you want to delve into the details underneath the enterprise architecture you could ask ‘where is the platform architecture’? Where have the decisions been made on which platforms will be the standardised for particular functional areas (be it business functions, integration functions, storage, etc)? This could also be called a technical reference architecture. But again, this misses the point of why I think this approach to EA is wrong.

What if you just had an enterprise architecture?

I have prepared a simple enterprise architecture for a client I’m currently working with. It is not the ‘master plan’. It is not divided into particular segments (except where they are formally seperate and independant business entities) – and may never be. It does not yet trace to a system architecture of any description. Nor does it describe any particular platforms, applications, technologies. There are a few IT related terms in the architecture but these relate to specific areas of functional groupings such as enterprise event management and shared data access which are important to the organisations operational processes.

Some people would say I have created an ‘enterprise business architecture’ and that this is just part of the enterprise architecture. But why is it only part? An application architcture doesn’t need to contain the code. The application architecture can be delivered without the code – so why can’t the enterprise architecture be delivered without the application architecture!?

Update to Enterprise Architecture Worksheet

By mdegeorge

On January 28, 2009

In Enterprise Architecture

I have updated the MWT/TEBT Enterprise Architecture Worksheet (pdf). The major change is that I have included a better template diagram. I have also included some references to the Enterprise Architecture As Strategy book which make it clear that a different diagram template is probably required for enterprises with different operating models. The worksheet is now suitable for a unification operating model as defined in the EA as Strategy book.

The reason for the update is that I have been trying to visualize the enterprise architecture of a client organisation I am working with and this process has helped my thinking. I’m a big supporter of the approach to Enterprise Architecture prescribed in Enterprise Architecture as Strategy. However, the client I am working with at the moment that has a number of important characteristics which don’t come out very well in the example and template EA ‘core diagram’ formats show in the book.

The book itself isn’t about a modeling notation so it doesn’t actually prescribe a specific diagram style. It’s focus in more iterative development of the enterprise architecture and the sequence of components to focus on during development of the architecture.

The organisation I am working with, while certainly operating under a Unification model at the highest level, has a number of unique pillars in their competitive strategy which don’t come out when taking the book’s approach. So I have altered the generative sequence for EA development in this organisation.

Firstly, the unique strategic pillars for this organisation are:

High need for operational capital
1. Resulting in a need to support the organisation’s share price
2. Resulting in a business segmentation strategy to increase visibility of value to the market
Need to manage markets and customer types across two distinct operations in order to remain competitive
Need for detailed product accounting to ensure accurate profitability of each ‘product’ can be determined
Need to be able to quickly change ‘product’ mix across two operations
A natural fit to a service oriented business architecture

Because of this I have developed a template EA core diagram structure which takes these into account. I believe it works very well for this organisation and others like it. I have included the diagram to the right with a full sized version (as well an overview of it’s main zones and analysis patterns) available in the pdf file.

Traceability in enterprise architecture

By mdegeorge

On January 27, 2009

In Collaboration Architectures, Enterprise Architecture, General MWT, Technology-Enabled Business Transformation (TEBT)

Whenever I read about enterprise architecture I’m always struck by how technical the conversation seems. I’m not anti-technical; but in my mind architecture is more important than what we generally call management. This is also implicit in the principles of the MWT Model. It is in fact architecture which I see as the centrally coordinating mechanism of organisations rather than management.

This means that at the specific level at which you are coordinating the architecture needs to be understood by all participants – not just technical people. If the level of coordination is the executive team making IT investment decisions the particular architecture is the enterprise architecture.

Now I’m the first to complain when IT Management becomes a race to the bottom and when IT Managers wear the statement ‘I’m not a technical person’ as a badge of pride (isn’t management ‘technical’?) but I’m talking about something different and specific here. If enterprise architecture has an intended audience that includes so-called non-technical people it cannot be technical.

The problem is, I find that enterprise architecture is always defined as something too all encompassing. It is always defined inclusively of all the business processes, goals, objectives, technologies assets, etc of an organization. It’s almost defined as something that isn’t valuable until it is complete at all of these levels.

However, this causes immediate problems that are reflected in every analysis of enterprise architecture (or failures in EA effort) that I ever read. It always appears to be that EA efforts fail because they are not maintained, through ‘lack of governance’, or that they are misunderstood or ignored by senior management.

Analysis of EA effort actually spent is one thing, but other field reports indicate that the effort never even officially gets off the ground before it’s too difficult to define the ROI of the investment. Nobody seems to question the ROI of dedicating resources to blocking and passively obstructing enterprise architecture efforts but that is another issue altogether.

I think the solution to these problems is very simple. It’s a solution that eliminates the high-cost of enterprise architecture initiatives (and therefore the issue of ROI), it also helps incorporate enterprise architecture efforts into the rest of the organisation (therefore making alldesign effort enterprise architecture effort), and it takes enterprise architecture to the board room (or at least the CIO’s office) where it belongs.

The three fifteen step plan for solving your enterprise architecture issue is as follows:

Hire a real enterprise architect
Establish only ‘dotted-line’ reporting to the enterprise architect
Use the phrase ‘enterprise architecture’ only to refer to ‘enterprise business architecture’
Establish ‘planned traceability’ from the EA to project documentation
Establish ‘planned traceability’ from the EA to system documentation
Establish ‘planned traceability’ from the EA to software development life-cycle (SDLC) documentation
Hold a workshop to established a baseline enterprise [business] architecture
Schedule reviews of traceability each 6 months for each application system
Include traceability reviews in the organizations project methodology at each phase gate
Schedule a review of the baseline enterprise [business] architecture yearly
Report, monthly, all EA traceability analytics
Publish a quarterly analysis of EA traceability analytics
Publish a whitepaper on how to interpret EA traceability analytics
Co-sponsor at least one project concept / idea per year with a business growth outcome based on EA-level transformation
Sponsor at least one project concept / idea per year with a IT efficiency outcome based on EA analysis and / or improving one or more measured based on traceability analytics

The most important step here is that you are no longer defining EA as a complete, integrated, end-to-end, endeavor. You enterprise [business] architecture is complete by step 7 above. It’s done. The assumptions about how value in the enterprise is generated are defined. The definition of enterprise architecture is also re-defined as only the enterprise [business] architect + the planned traceability to other key assets. In this sense, your EA is complete.

Steps 8-10 ensure that your enterprise architecture is always up-to-date. But up-to-date shouldn’t be read to mean complete. The EA is up-to-date in the sense that the enterprise [business] architecture is up-to-date and you know the status of all traceability. Within the status of the traceability is the key to understanding how complete you understanding of systems is – including the completeness ‘alignment’.

Steps 11-13 ensure that the information in the EA is known, understood, and utilised for decision making. Steps 14-15 ensure that the enterprise architecture (and the enterprise architect) delivers value. It also allows for additional specific, targeted EA effort to be managed through the normal project approval processes.

If the following steps are followed – and this of course depends on you finding a ‘real’ enterprise architect to hire – you will be well on your way to best practice in enterprise architecture. More importantly, the communication and organizational engagement issues will be solved. If you have hired correctly, the enterprise architect will also be an enthusiastic and invaluable member of the IT management and / or executive team.

As far as EA becoming more valued than ‘management’, I’m not sure when this will happen. But if we can stop whining about how difficult it is to get EA established and get on with the job (see above process) we at least won’t need to defend our failed efforts anymore.

What’s good for Obama is good for General Motors

By mdegeorge

On November 12, 2008

In Current Events, Enterprise Architecture, Technology-Enabled Business Transformation (TEBT)

There is something particularly exciting about Barack Obama’s plan to appoint a government chief technology officer. Not only is this good for government, but it’s also good for the IT industry. Like Ron Tolio of Cap Gemini has said:

No half measures. And quite a strong message to many corporations that struggle with the role of IT in business. This is far from the marginalised position of an IT manager who apathetically reports to the CFO about cost cutting and risk management. This is a boardroom position, one that is supposed to create strong impulses for change and growth.

There is a real difference between a CIO that is charged with ‘serving the business’ and one that is charged with ‘getting value from IT’. You can serve the business by saying ‘it’s the business’s money therefore they get to decide how to spend it’. But to commit to delivering value out of IT you have to commit to business benifits and a business return of technology spend. You need to actually contribute to the strategy and deliver growth through technology spend.

It doesn’t matter what type of CIO you are. As long as you know what is expected you can be successful. But if you are successful purely because you have moved investement decisions to business units, who is ensuring that you are getting the most value out of IT? Is IT actually contributing to the organisations strategy and growth?

Anyway, it’s also good to see a few of these sites popping up too. ObamaCTO.org allows anybody to suggest ideas for the CTO role, which are then voted on and ranked. Now this sort of system is still susceptible to manipulation by special interests. But it’s transparent – and that’s all you can do.

The Enterprise Architecture Network Google Group

By mdegeorge

On October 31, 2008

In Collaboration Architectures, Enterprise Architecture, Technology-Enabled Business Transformation (TEBT)

The Enterprise Architecture Network Google Group has soon good disucssions. Though it sometimes goes beyond what I would strictly call ‘enterprise architecture’; but most EA discussion do. I would recommend joining it to connect with other architects. You also have to be a member of the related LinkedIn group.

More for my own reference, here is a contribution I made to a recent discussion on the difficulty in determing an ROI for an enterprise architecture practice:

Hi

I think it’s unfortunate when we are asked for an ROI for developing a EA practice. This is like asking for the ROI of having a project manager. It’s probably a good question, and I’ve asked it myself, but some things need to be sacred so we can just get on with the job.
I’d never ask for the ROI to set up an EA practice – to me this is sacred – because I’m sold on the idea already, as long as it’s small. I think we need to sell EA more so less people ask for an ROI. But I also think that means changing slightly how we currently define EA. It also means we need a response when people ask for an ROI…

This is why I’m so interested in how we define what EA actually is. I think we should define EA solely as what some on this group might call Enterprise Business Architecture (EBA). The other deliverables, work products, initiates, etc should be traced to that EBA but we shouldn’t call that the EA. We also shouldn’t say the EA is complete only when all of the IT components properly align to it. We should simple do the EBA – showing value streams, key customers, service strategies for the enterprise, etc – and trace to the minimum asset types required to get calculate baseline alignment to the EA.

The reason I say this is because you can’t define a return on investment for developing an EA practice except in terms of improving decision making relating to IT investment. You are looking to improve alignment to the EBA over time, but you can’t do that from the EA practice itself. You can only do that by influencing IT investment decisions. Unfortunately, a more general tool already exists for improving decision making relating to investments. And that’s the ROI calculation.

The problem is nobody ever asks ‘What is the ROI of determining the ROI?’, nobody ever asks the question ‘What is the quality of the ROI calculation?’, and nobody ever asks ‘How is the ROI process performing?’. There is a bunch of IT effort being spent which roles up into the ROI calculation and unless you think your IT systems couldn’t be any better at this point in time, it’s not working.

Whether it’s formal or informal, organisations already think they are making decisions to maximize return on investment. The problem is, in the area of IT investment there is no formal method of determing the inputs which go into the calculation of return on investment. Also, the inputs must take into account the value streams of the business, IT costs, changes in IT cost structure, and changes in business cost structure. IT initiatives move costs into IT while creating activities/costs to be performed by users outside IT. As such, IT can’t determine ROI itself because the initiatives transform more than just the IT organisation.

An EA practice should formalise that process of determining the inputs into ROI calculations. It should also allow the performance of that process to be managed over time. By the way, within the phase ‘IT initiatives’ I am also including that particular type of project I like which is technology-enabled business transformation.

Other initiatives – business initiatives – simply need to include the costs of IT in their ROI calculation. IT cannot, by itself, commit to all ‘returns’ which are outcomes of IT initiatives. This doesn’t mean IT can’t run business transformation programmes. It simply means that any initative of this type requires communication, traceability, and modeling across multiple disiplines. And it needs this even to calculate the ROI.

EA, in the strict sense of Enterprise Business Architecture, is the basis for not only IT strategy, but also for IT investment decisions. EA, in this sense, is the baseline level of knowledge and process required to make ROI calculations for other IT initiatives. So asking for an ROI for and EA practice which analyses the value streams of an enterprise and traces these to technical and organisational components is like asking for the ROI of developing high quality ROI calculations.

By the way, it’s possible that a particular CIO doesn’t have the responsibility for delivering value from IT investments. In some instances the IT function doesn’t technically run even IT projects. Instead these projects are ‘business projects’ relying on IT only to deliver a defined set of IT services. However, this is a dangerous position for a CIO to be in. It also just means that the EA practice should be sponsored by somebody else who does have that responsibility. It doesn’t mean that (a small) EA practice shouldn’t exist.

Regards,
Matthew De George

Enterprise Architecture: ‘New’ to MWT

By mdegeorge

On September 29, 2008

In Enterprise Architecture

The MWT/TEBT Collaboration Architecture recognises that when technologies successfully transform businesses they often do so through sharing and/or standardisation of business processes and data. It is this standardisation which allows greater transparency of operations (and operational risk) as well as ultimately enabling the implementation of the market-based approach at the heart of the MWT Model.

However, when it comes to defining and selecting which technology-enabled business transformation (TEBT) initiatives to perform, there is an overlap between the MWT Model and the most useful parts of what is called Enterprise Architecture.

Where enterprise architecture relates is in developing the collaboration architecture (to use the MWT term) to enable the senior executive team to have discussions on organisational value – and ultimately what processes and data should be standardised and/or shared via technology implementations.

Many enterprise architecture treatments focus only on optimising the platform architecture of the enterprise. This makes many enterprise architecture discussions far too technical. Also, from an implementation perspective, standardisation on platforms may actually be too expensive to ever implement; while at the same time it may provide less value to the enterprise than other initiatives could have. Discussions on enterprise architecture that fall into this category may in fact reduce IT spend while losing focus on the knowledge and related IT capabilities which could increase the value of IT.

One book that doesn’t fall into this trap is Enterprise Architecture As Strategy: Creating a Foundation for Business Execution. I strongly recommend it as an introduction to this topic. I have also added an Enterprise Architecture blog category to tag future posts on this topic.

Bailout reader

By mdegeorge

On September 29, 2008

In Austrian Economics, Current Events

Mises.org has released an interesting Bailout Reader of articles and other literature relating to the current ‘financial crisis’ in the US. It basically says ‘Ha! Look how clever we were predicting this; and look at the theory that we refer to when we predicted this because it has some interesting things to say about the proposed solution too’.

I’m paraphrasing – but it sounds about as arrogant as that. But you can sound arrogant irrespective of whether you are right or wrong. I recommend reading a few of the articles and core literature because I think they are right.

What I don’t really understand is why it’s the corporations that need to be bailed out. If you look at the bill itself its purpose is to save home values, collage funds, etc. But these things can be saved more directly. I don’t see why, in the scenario where somebody can’t afford to pay their mortgage, we give money not to the person who doesn’t have the money but to the bank that gets the house but can’t sell it for the full value!?!?

Multisourcing disipline: ‘New’ to MWT

By mdegeorge

On September 29, 2008

In Multisourcing

There is no avoiding it. There is an overlap between some aspects of the MWT Model and what is increasingly called Multisourcing.

The Multisourcing dicipline really is beyond procurement, outsourcing, and supplier management. Multisourcing is both a strategy and a strategic capability of the client organisation. It is the end-to-end process of service definition and management, selection of who will perform services, decisions on where services will be performed, and the related governance and performance management.

Though in truth, the diciplines relating to Multisourcing can be relivant even to organisations which deliver services using predominately on-shore, in-house capabilities. This is where it relates most interestingly with the MWT Model and service-based management in general.

I have created a new blog category for posts relating to Multisourcing. This is such an important disicpline I would expect these would be of interest to anybody with an interest in the MWT Model.

If you’re already keen to learn I recommend Multisourcing: Moving Beyond Outsourcing to Achieve Growth And Agility.