Playing cards for the enterprise

I've just been lucky enough to spend a few days with Tom Graves, brought in to give our business architecture vision and approach a shot in the arm. His recent post describes his approach.

One of the things he spoke about was the 4 dimensions of an enterprise (or its context, or a service within it): relations, purpose, stuff and knowledge. These are similar to, but go beyond, the familiar people, process, technology triad (with information at their intersection). They fit with the view that a living organism with intent is a better metaphor for the enterprise rather than just a machine with processes. That seems to fit with original systems theory too.

Anyway, we spoke a bit about playing games to help draw out the big picture of the future enterprise. As a consequence, I've had a go at making a deck of cards with a suit for each of the Tetradian dimensions.

• Our organisation already had a published vision with 8 headlines could be read as our purpose. I added 4 more cards for the unstated tacit goals of the council too.
• Coming up with classes of people that the council relates to was also quite easy following Tom's workshop. I made 8 cards for them, then another 8 for other key organisations that we work with.
• Finding just 8 types of knowledge or information that are core to the enterprise and our operating context was a bit more more difficult. We have a quite well developed  catalogue of information assets already modelled in our team, but it seemed something more generic was needed for the wider top-level context.
• Defining 8 classes of stuff was also challenging, and it's possible those I came up with are too generic to be useful, but I thought they'd do for a first attempt.

The next step is about trying to find something fun and useful to do with these 44 cards. The could just be put on one poster, like a level 0 data flow diagram or a single Eriksson Penker process that says what the council does - in bidirectional interaction with all those people and organisations, using the identified information and stuff, and working towards the purpose-goals.

It makes more of a game, though, to shuffle the cards and deal them out until you've got at least one of each suit. The challenge is then to make a story for how those actors interact via the council, using the things and knowledge items turned up, whilst supporting one or more purposes. There should be two versions of this story - what happens now and what ought to happen in a leaner and more effective 21st century council. After playing this a few times, regular patterns behind the stories may emerge, and these represent the services that the council ought to be doing.

I'm hoping that these cards help with the question "what's the story". Even with our vision, we struggle to define the roadmap for our IT applications and service modernisation. Though playing with them is only a game to get discussions started, they do link directly to Tom's enterprise canvas and can be mapped to other frameworks too.

Lifecycles for a system of systems

Following on from the previous post, I was wondering whether any of the established lifecycle views really fit with a systems-thinking view of the enterprise as a system of systems. With a software engineering background, the first lifecycles that come to my mind are those for software development, e.g.:

• Waterfall - the sequential flow from requirements via analysis, design, coding and test to operations, often credited to Winston Royce. Note even in Royce's original paper on this from 1970, iterations and routes back to previous steps are anticipated.
• Spiral - as in Barry Boehm's original from 1986. Note how this includes the customer at the opposite side of the cycle (i.e. accepting objectives for the next iteration) from release (i.e. passing user acceptance testing). Also, this seems close the Deming plan-do-check-act (PDCA) cycle that's applied in ITIL continual service improvement.
• Agile - I guess the core of Agile is defined by the 2001 manifesto, but the earlier Scrum is a more concrete process based on it. I've also saw software developers naturally adopt Extreme Programming (XP) methods (like paired programming, test first and customer inclusion) before Kent Beck published. I'd like to say more on this in later posts too. 

But through experience of applying enterprise architecture to public sector systems integration problems especially, I now use some other lifecycles as points of reference:  

• The V model - which can bee seen as a way of rearranging the waterfall so that the link from earlier to later steps can be shown. The INCOSE Systems Engineering Handbook has a reference lifecycle, though I don't think the actual V diagram was in the version I used; it is a standard in Germany though. This works better for large systems than a simple waterfall, as the difference between testing components of an architecture, the design's verification and the validation of the solutions' integrated behaviour is clear.
• CADMID - the sequence of concept, assessment, demonstration, manufacture, in-service, and disposal was used by the UK MOD and others (e.g. for teaching at UCL). This sequence partly reflected the bureaucracy of different stakeholders, especially when the roles of capability sponsors and procurement were clearly split (set up for good reason, considering the costs and risks in MOD programmes that are both critical and innovative). 
• The TOGAF ADM - which in contrast seems targeted at business change programmes (for example, rationalisation of a business and its systems following the merger of two organisations). 

A few questions could guide thoughts on applying these:

1. How do these apply to the more organic evolution of a system of systems? 
2. What does that mean for stimulating and exploiting innovation?
3. So which is/ should be the reference to follow for a council's information systems?

Motivation to blog (and model IT)

Information systems architecture at a local authority. It sounds like a bit of a niche interest or career, but I believe it really does matter. 

I've studied and practiced enterprise architecture for several years, building on a software architecture background. If it works, enterprise architecture provides a consistent, structured description of a whole organisation. That's not a complete description, but a slice through it from a certain perspective - with information at its heart. But information only works if people have the right tools that use it to help them do their jobs - that's the trinity of people, process and technology that enterprise architecture captures. A holistic model can help rationalise merging businesses, or describe how a strategic vision to do something new will work.

But my experience is in public sector where a key challenge that keeps coming up is just getting information systems working together. There may be old IT, procured in a departmental stovepipe, but services that must be delivered by staff working together. Also, improvements are needed to meet 21st century citizen expectations, whilst ensuring value for tax-payers' money - even before factoring in austerity cuts.

So how does enterprise architecture help the people who a city council serves get better services for less? I hope we'll find out as I blog here!