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?

The city is a system of systems...

...and council information systems help keep it alive.

From my limited understanding of systems theory, its key foundations were laid by Bertalanffy and others in the 1950s, and Bertalanffy was a biologist. So whilst I'm looking for ways to systematically understand and analyse information systems, there is this wider established systems discipline that applies as well to organisms, human behaviour or, I'm sure, cities as much as computing systems. 

Original systems theory defined an open system as one that draws inputs from and emits outputs to the environment it's in. In this way, it can avoid running down from entropy and keep operating in a steady homeostatic state, reacting to environmental changes. For organisms, inputs are solar energy and specific chemicals, whilst the outputs that are waste for one organism may become inputs to others. For humans, other social animals and computer systems, information can also be input and output. The city qualifies as a system because it sustains itself through time, absorbing energy, resources and information whilst generating physical and cultural outputs. It can also carry on through changes, from daily and seasonal cycles to changing populations, technology and economic fortunes.

If I try to visualise this schematically, two specific structured diagram standards come to mind:

• IDEF0 function modelling method from the 1980s, 
• and the UML-based process modelling approach of Eriksson and Penker from their 2000 book (also supported by Sparx Systems' Enterprise Architect tool). 

I don't know how closely these approaches were based on classic systems theory, but a simple comparison of their core diagram components is below. All three help show that systems are dynamic, with purposeful behaviour that reacts to changes the environment they're in.

Open System	IDEF0 Function	Eriksson Penker Process

So the city is a system, the council is part of that system, and the council's operations depend on its IT systems; the city is a system of systems. But when engineers talk about a system of systems (SoS), they can mean it has specific characteristics. I can't link a definitive list for these - I learnt from a former colleague, Alan R, and others who'd attended INCOSE meetings. They taught me that the key SoS characteristics are:

• The overarching capability or service delivered by the SoS arises from its independent parts working together; the component systems have connecting interfaces to support end-to-end flow.
• Some level of service can be delivered continuously; components can be swapped out and replaced. This is different to a system delivered by a project, which typically has a step-jump in capability when it goes into operational service.
• Parts of the SoS are developed and maintained by different organisations for their own purposes and independent business models; nobody is in complete control.
• A SoS's behaviour and qualities are emergent, and may not be predictable.

I've seen SoS thinking applied to engineering challenges, for example: search and rescue (from distress beacon pickup to coordinated response), critical national infrastructure security, and environmental science missions (combining space and ground-based sensors). But it applies to city services as well (which themselves overlap), for example: 

• Care delivery - by the NHS, private and public facilities, charities and individuals.
• Education - including school transport and addressing special educational needs.
• Transport - traffic operations, street asset and infrastructure maintenance, improving environmental impact and journey times.

So in conclusion, it's worth keeping systems thinking in mind when looking at the council's IT estate. Specifically, a systematic way to capture how things relate in a dynamic system, like Eriksson and Penker's, is worth keeping handy in the modelling and analysis toolbox. Also, when thinking about an information system's environment, it's worth remembering that it's value is from its operating context in a system of systems, with all that implies. That's especially important when a task becomes focused is on specific project's delivery or change programme's goal.

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!