Category: Collaboration Architectures

This is nice.

My favourite section:

“There’s no management when we’re three people. There’s no management when we’re 15 people. We still don’t have any managers hired in 37signals. Every single one of us are producers.

I’m still a producer. I still write code. Jason still designs. We still do all the stuff and management is sort of the offshoot of, “Oh, yeah. Sometimes we have to deal with issues that they come up.”

Problem is when you have actual managers, whose sole job it is just to manage, they make up [stuff] to manage because you’ve got to fill an eight-hour day.

And in the beginning, there’s 40 minutes of management every three days. That’s what you need for management. You do not need eight hours of management, which is how you get policies and all this other bull that crops up when people don’t have anything to do.

Idle managers are absolutely the worst.”

– http://ecorner.stanford.edu/authorMaterialInfo.html?mid=2351

(this is cut-and-paste from the transcript so I can’t remember what particular exploitive they are editing when they say [stuff])

Breaking down innovation accountabilities

By mdegeorge

On March 25, 2010

In Collaboration Architectures, General MWT, Innovation, Personal

I’m attending an ‘innovation workshop’ today. I’m looking forward to it but it also feels a little bit dirty. Innovation is important – but I’m not sure it can be managed directly. Management of anything politicises it; but with vague notions like ‘innovation’ it’s hard to establish the accountability required to balance the politics.

The session today will interesting. I’m sure we will have the inevitable ‘what is innovation?’ discussion. But I’m sure the normal process of people wondering how this might help their career will interfere with that. Also, participants come from multiple vendor and client organisations so this will limit the sorts of ideas that can be discussed.

I’m not lamenting this dynamic – it’s a natural part of work life. But the trick will be to quickly convert this forum into a set of processes that ensure value is directed towards the sponsoring organisation. I believe breaking up ‘innovation’ into a number of separate processes for which accountabilities can be established is the answer to this.

My first cut of the breakdown is as follows:

Idea management process (capture, rate, sponsor, formally reject, and reward/recognition)
Scanning (internal and external scanning of practices, technologies, and trends)
A formal approach to analysing the organisation
Initiative delivery process (to manage sponsored initiatives)
Slack for brainstorming and black-market idea generation

Some of these, such as scanning, may have separate accountabilities for each organisation (to create competitive tension). The idea management process may be owned by the sponsoring organisation (to ensure transparency to the sponsoring organisation). Items 3 and 4 are likely to be tendered. Item 5 may be measured by the innovation forum but be considered an accountability of business units.

Explicit collaboration

By mdegeorge

On March 8, 2010

In Collaboration Architectures, General MWT

MWT Collaboration Architectures are a critical component of the MWT Model. In short, a collaboration architecture defines how individuals collaborate on a particular task. As with most architecture work, the focus is on what needs to be shared and what needs to be standardised.

Collaboration architectures are not sequential (though there my be some shared sequences for some collaboration architectures) and importantly these are not collaboration processes. Rather than roles and responsibilities their is just enough of a shared framework where the right roles and responsibilities emerge. There is also just enough of a shared understanding of risks so that their is reward in putting effort into risk mitigation rather than an incentive to avoid working on activities with inherent risk.

It’s a simple concept but effective collaboration is not something the management discipline currently guarantees. General management provides a mechanism for defining roles and responsibilities; project management provides a means of managing costs, schedule, and risks; and there are of course disciplines of around strategy to get things started, and conflict management when none of this works are it should.

But ultimately there isn’t a lot of focus on how individuals need to actually collaborate around a set of shared artifacts in order to get something done. It’s been over-stated already – but this situation is not acceptable in the information age. But nor has it been corrected by the information age. Business process management (BPM) technologies are rarely implemented – and when you look at the types of processes they are able to support (i.e. Non-collaborative) that’s almost certainly a good thing.

What’s more, managers themselves are currently facing increasing pressures from the communication technologies that could otherwise support more effective collaboration. Management disciplines are sufficient if the right information gets passed through the manager. But communication technologies, resource mobility, and distributed workforces mean this simply doesn’t happen. Managers are left in a situation where they don’t know what is going on but are still responsible for it.

I’m seen managers response to this challenge in precisely the wrong way. For example, consider the phrase ‘I only need to make sure my direct reports know what they are doing’. I’ve heard this before and it drives me crazy. This is like saying ‘I’ll just manage myself, not the organisation’.

In addition to the above sort of reaction I also see a lot of cases where managers simply refuse to integrate communication & collaboration technologies into their management process. In this case, there is potential for transparency and technology-enabled collaboration but the managers don’t want to use the tools. If the tools are then used in this environment the whole management process can break down because sufficient information isn’t passing through the manager.

I can already hear ‘tools wont solve this’ echoing in my head as I type. This is partially true but the management discipline itself is a tool. All those catch-phases like ‘we need to work together’ and ‘I don’t want to get involved in the details’ are tools. Similarly the phase ‘make sure you CC everybody in the team on every email’ is a tool. But they aren’t tools that help the organisation!

Introducing Human Interaction Management

As I’ve been working through MWT Collaboration Architectures I’ve come across some work on Human Interaction Management (HIM). I’m please to note that work in this area has a lot of similarity to the MWT Collaboration Architecture approach. I’m sure it also has adoption challenges as per the discussion above.

If you’d like to read more about HIM try the following links:

‘The First Step for BPM is HIM’:

http://www.bptrends.com/publicationfiles/ONE_07-09-COL-HumanProcesses-Harrison-Broninski-final.pdf

A ‘Human Interaction Management’ portal:

http://human-interaction-management.info/

Google Docs isn’t the answer:

http://www.information-age.com/research/276941/riding-the-fourth-wave.thtml

Work 2.0:

http://www.peterfingar.com/Work2-0.pdf

“Why Workflow Sucks”:

http://www.ebizq.net/topics/bpm/features/7462.html

Presentations and podcasts for people who don’t read good:

http://harrison-broninski.com/keith/him/presentations.htm

The book:

http://www.mkpress.com/hi/

Project Managers Should Not Fear the Baseline | CIO – Blogs and Discussion

By mdegeorge

On February 15, 2010

In Accounting Failures, Collaboration Architectures, General MWT, IT Management, The New MWT Hierarchy

There is some wisdom in Jim Vaughan’s article and the related comments:

The poor performance of the project usually has less to do with the project manager or the project team and more to do with the systemic failures of the organizational culture to provide the proper tools and governance to allow the projects to succeed. These systemic issues really become the moose on the table that no one wants to talk about. As a result the PM and/or the project team are blamed for the failure.

via Project Managers Should Not Fear the Baseline | CIO – Blogs and Discussion.

The Professional Mess

By mdegeorge

On December 23, 2009

In Accounting Failures, Collaboration Architectures, General MWT

There is a very interesting interview with Dr. Thomas Dorman on the Lew Rockwell podcast entitled ‘The Medical Mess’.

Dr. Dorman talks about how placing an intermediary between a professional (the doctor in this case) and their customer (patient in this case) destroys the relationship between the doctor and the patient.

I think anybody, not just Doctors, who considers themselves a professional will recognise the sentiments Dr. Dorman highlights as common to the experience of being over-managed and under-lead in many a large organisation.

In summary:

The intermediary breaks the clear ‘point of transaction’ at which point the consumer owns the service provided – creating arguments and errors which then require regulations
Regulations require the professional to ‘code’ medical conditions and categorise medical conditions based on the codes specified by the intermediary
Because payments are made based on these ‘codes’ it forces the professional to spend considerable intellectual effort on the management of codes – at the expense of spending intellectual effort on the service
Also, ‘if there isn’t a code for something there isn’t a service’. So ‘codes’ must be manipulated to order to produce ‘a fair outcome’. This creates mistrust amongst all parties.
Professionals then spend time ‘documenting things to the satisfaction of the inspectors’ rather than working on services. This amounts to ‘costs escalating exponentially’
This intermediation process is ‘known not to work’ in that it doesn’t create a more effective services. So ‘there must be an agenda’
This agenda is ‘control, rather than providing quality services’

Sadly, Dr. Dorman passed away earlier this year before I even listened to this podcast. The ideas, as always, live on.

No wrong way to slice the pie? (and do you even know?)

By mdegeorge

On May 7, 2009

In Collaboration Architectures, Enterprise Architecture, General MWT, IT Management, Multisourcing

Management, as a discipline, has a problem it can”t solve. It needs to coordinate separate but related activities caused by the division of labour. And it needs to be able to do this regardless of how labour is divided.

Project management, in particular, has this problem. I’ve said before that project management is a perfectly reasonable discipline as long as it doesn’t try to cross organisational boundaries. This is why project management is necessary but not sufficient in managing outsourcing.

Likewise, program management – which the discipline likes to define as the management of multiple related projects – isn’t really a separate discipline because of the scale of the work or the number of projects, it’s a separate discipline because multiple projects have multiple project managers.

Unfortunately, the accepted tenets of management simply do not scale. Multiple managers causes more problems than they solve – and therefore situations which require multiple managers need other practices to govern them.

The root of this problem is that ultimately, the discipline of management doesn’t in itself offer any useful advice on how to divide labour. It takes it as a given that labour is divided and then attempts to coordinate that.

Equally, managers – when you switch them on and give them responsibilities – tend to manage to those responsibilities. Good so far, but if the division of responsibilities isn’t right there is a problem. The problem might even get bigger if the managers are better.

But there are right and wrong ways to divide labour. Some activities are autonomous and some aren’t. Dividing management responsibilities and activities has its own additional challenges.

Only ‘architecture’ (which I define in this context as deliniated shared understanding) can offer any help in the actual division of labour. However, architecture must be domain specific. In order to determine correct/incorrect or efficient/inefficient divisions of labour it must take into account the domain and the required outcome.

(by the way, if you think a ‘strong management team’ solves this problem check out my article on ‘Management Teams as Cartels’)

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!?

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.

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