This article is a first draft on what I think will become an increasingly important thread. Complexity has caused some serious and extreme failures in other areas of the Public Sector. The UK National Health Service “National Programme for Information Technology” project is just one of many high-profile, massive Public Sector ICT projects around the world that have buckled under the weight of their own complexity. As schooling ICT systems develop in sophistication and scale, it’s a reasonable assumption that the struggle against complexity in this area will increase significantly.
A Simple Model Of Complexity
Take 12 dice, put them in a bucket and give the bucket a shake. Pour the dice on the table. How many possible combinations (states) could you have? The answer – 2 bn. To be precise, where you have 12 components each with 6 possible states, the possible number of states is 612 = 2,176,782,336. So what has this got to do with schooling ICT?
The dice example is a metaphor for how complex any ICT system can be. Each component in an ICT system – software, hardware, process, workflow etc – can all exist in many different states. A single piece of software, with 12 variables each with 6 possible states would have in excess of 2bn possible states. Likewise, a process with 12 decision points, each with six possible paths would also have over 2bn possible states. Combined, these systems have trillions of possible states.
So what does this mean to you? If your role involves responsibility for complex systems – either in a management or technical capacity – having a method for dealing with complexity will likely be very useful indeed.
Let’s begin by acknowledging that complexity is the enemy of effectiveness and efficiency. Complexity costs money and can cause systems fail to get off the ground, or collapse when they are running. Removing complexity removes costs – and lowers risk too – so it’s well worth thinking about. This article sets out a V1.0 five step processes for driving out complexity from your systems. Parts of this are based on a wonderful piece of work on this area by Roger Sessions called “Simple Architectures for Complex Enterprises”, which I strongly recommend. The method has 3 elements:
- A container
- 5 steps
- A maturity model pathway
Container – Enterprise Architecture
The 5 step process – which we’ll call “Schooling ICT System Simplification” – sits within the context of Enterprise Architecture. This is the container for all the components and relationships within large, complex systems. Three definitions are important here:
- Enterprise: a collection of organisations that share a common set of goals. Enterprise in this sense does not mean “business”, though businesses can be enterprises.
- Architecture: a system’s components and the organisation of how they relate to one another.
- Enterprise Architecture: a description of the goals of an enterprise, how these goals are realised by processes, and how these processes can be better served by technology.
Enterprise Architecture (EA) is a 20 year old discipline, and is used to organise technology to add value in complex organisations.
There are several “off-the-shelf” Enterprise Architecture methodologies that one could use, eg:
The Queensland Government in Australia also has some potentially useful thinking in this area with their “Queensland Government Enterprise Architecture 2.0”
These can all play a role in schooling systems, but schooling has some very specific structures and requirements that would require a ‘standard’ EA to be adapted considerably. This is why I wrote Schooling at the Speed of Thought – the goal of which was to help schooling systems develop a domain specific version of Enterprise Architecture called “Schooling Enterprise Architecture” (SEA). Since writing Schooling at the Speed of Thought I’ve updated SEA to Version 2.0 below.
“Schooling at the Speed of Thought” was designed to take organisations a long way towards defining their goals, how these goals are realised by processes, and how these processes can be better served by technology.
With Enterprise Architecture established as the container for all activities relating to developing ICT systems, the next step is to embark on the simplification process itself.
High quality decision making is the bedrock on which reducing complexity rests. You will need an organisational model for how decisions will be made, how responsibilities will be delegated and performance managed. At the SEA level, we are not concerned with the “how” (the ‘nuts and bolts’ of developing solutions) but the “what” – ie what does and what will our organisation do. However, the SEA team needs to be responsible for directing the policies that shape how solutions projects are executed and the higher level architectures and standards that they should work within.
Key SEA governance issues include:
- Composition of the SEA team
- Reporting structures for the SEA team
- Processes for introducing functional components into the SEA
- Ownership and management of the SEA development process
- Ownership and management of the component inventories, taxonomies, standards, and technical infrastructure
- Management of the technical infrastructure
- Ownership of knowledgebase – i.e. SEA documentation and architectural designs
Governance should ensure that there are processes for:
- Documenting organisational requirements
- Managing artefacts
- Establishing solution project requirements
- Measuring milestones
- Showing delivered value and ROI
A Schooling Enterprise Architecture can be reduced down to functional components and the relationships between them. Key questions at this stage are:
- What are the goals of the organisation?
- How is the organisation structured into processes?
- How do those processes relate to one another?
- Which processes can be best improved through technology?
- What is the plan for making those improvements?
Before we look at this further, let’s return to our dice analogy – starting with two dice in one bucket. On average, it would take 36 throws to get the same outcome (e.g. 2 sixes). Separating the dice into two buckets, we have to throw the dice six times in one bucket then six times in the second bucket to get the same outcome – a total of 12 throws. Applying the same maths, splitting up 12 dice in one bucket into 12 buckets each with one dice reduces the number of throws to get the same system state (say 12 sixes) from 2.2bn to 72. This is because we split the process of getting 12 sixes into 12 consecutive events, rather than waiting for the combination to occur simultaneously. In other words breaking up a tightly coupled chain of components into independent (autonomous) components radically reduces complexity. Mathematically, this is known as partitioning, and it can be applied directly to complex organisations.
For the sake of clarity and consistency we’ll call the functional components in a SEA “Autonomous Functional Capabilities” (AFCs). AFCs are the fundamental building blocks from which an SEA is built. They contain two components – “Process” and “Technology”.
‘Autonomous’ means that they can function independently of other AFCs; ‘Capability’ means that they can produce something tangible. We are only concerned with what AFCs do and how they relate to one another.
We use partitioning to make sure that every function of the schooling system lives in one – and only one – AFC. This means ensuring that they are made up of unique components, and their functions don’t overlap with other AFCs. Importantly, AFCs can be composed of other AFCs.
AFCs are not completely random with respect to one another as are dice. Typically, there will be interactions between AFCs – eg messages or database sharing. A design goal then is to minimise the number and complexity of interactions, balancing needs for interoperability between AFCs whilst controlling complexity inside AFCs. This means carefully defining relationships and using as few relationship categories as possible – these are typically:
- Information Request
- Information Broadcast
- Work Request
AFCs can further be categorised as follows:
Mapping the entire organisation, using partitioning to “decompose” functions into AFCs, and defining their relationships can reveal the full extent of organisational complexity, and pave the way for further simplification.
The next step in reducing complexity is to rationalise the map that we have created in step 2.
Returning to the dice analogy, another way to reduce complexity would be to reduce the number of dice in the system. In ICT terms, this means removing functions that are not absolutely necessary. It’s about ensuring that every function is linked to an explicit, concrete, and quantifiable requirement. It is also about looking for consolidation opportunities, and asking if there is already an implementation of a given AFC type that can be tweaked. Functions can also be removed by outsourcing them, and Cloud computing is opening opportunities for doing this.
With the SEA now analysed, mapped, partitioned and non-core functions removed or outsourced, the next step is to prioritise which new AFCs to implement or develop. The following factors should drive the prioritisation of which AFCs to fund:
- Value drivers – e.g. cost savings, increasing learning, providing access to opportunities
- Risk – organisational and technical
- Organisational readiness
- Team readiness
- The cost of not deploying an AFC
Above all else, these factors should be quantifiable and easy to display together visually in a Radar Graph. Politics also plays a part in prioritisation, and often it makes sense to prioritise AFC deployments towards high impact, low risk and low cost. Creating short term, high visibility wins helps attract support for broader initiatives.
We can define the term Solutions as “a managed package of technologies, services and programmes that together solve an organisation’s problems or address new opportunities”. Solutions sit inside Enterprise Architectures and are the projects by which an organisation can achieve new levels of maturity. A solution project can address low level point problems, such as printing, or high level opportunities such as complete organisational transformation. Enterprise Architecture is the “what”. Solution projects are the “how”.
There are several layers of prescriptive guidance to consider when building solutions:
There are several solution methodologies to choose from. TOGAF and the Zachman Framework are both Enterprise Architecture approaches and solution methodologies. However it’s the Microsoft Solutions Framework that seems to work best on complex schooling solutions projects. Whilst devised by Microsoft, this methodology is completely technology agnostic.
MSF is made up of prescriptive models and disciplines that guide solution projects through from inception to delivery.
The MSF Process Model consists of five phases:
This is about creating a broad description of the goals and constraints of the project. In this phase, you identify the solution team and what the team must accomplish for the customer. The purpose of the envisioning phase is to build a shared vision of the project among all the key stakeholders of the project.
This phase culminates in a Vision/Scope document, agreed and approved by all key stakeholders. The document sets out what the project aims to achieve, what is in and out of scope, the project structure and a risk assessment. The document is built during an envisioning process that includes the following steps:
- Defining the goals
- Defining the project structure
- Setting up the team
- Assessing the current situation
- Creating a vision statement
- Identification of the scope of the project
- Defining requirements and user profiles
- Developing a solution concept
- Assessing risk
The Planning Phase
Deliverables of the planning phase are:
- Requirements: Organisation; User; Operations; System
- Use scenarios and use cases
- Functional Specification—including design and architecture
- Master Project Plan and Master Project Schedule
- Development, testing, and staging environments
The main outcome of the planning phase is an approved project plan — due dates that are realistic, project roles and responsibilities that are well defined, and everyone agrees to the deliverables for the project.
The Developing Phase
In this phase, the team develops the infrastructure for the solution. This involves the source code and executable files, installation scripts and settings, and support elements.
The development process includes creating a prototype application; developing the solution components; completion of all features; and delivery of code and documentation.
Stages of the developing phase are:
- Proof-of-concept application
- All features complete and have gone through unit testing
- The product is ready for external testing and stabilisation
- Customers, users, operations and support personnel, and key project stakeholders can evaluate the product and identify any issues that must be addressed before the solution is shipped
The Stabilizing Phase
At the end of this phase the solution will meet the defined quality levels. The stabilisation process involves running the solution in a staging area with actual users and real usage scenarios, including an extensive and comprehensive range of tests.
The stabilizing phase goes through the following stages:
- Zero-bug release
- Release candidates
- Golden release — zero-defect and meeting success criteria metrics
At the final release, the responsibility for managing and supporting the solution is officially transferred from the project team to the operations and support teams.
The Deploying Phase
During this phase, the team deploys the solution technology and site components, stabilizes the deployment, transfers the project to operations and support, and obtains final customer approval of the project.
Deliverables of the deploying phase
- Operation and support information systems
- Documentation repository for all versions of documents and code developed during the project
- A training plan
- Project completion report
Deploying new solutions can be a source of complexity if large numbers of AFCs are rolled-out simultaneously. It’s better to roll-out a single AFC on a small scale, and quickly, and then add other sites and related AFCs over time, rather than attempt “Big Bang” deployments.
Solution Architectures differ from Enterprise Architectures in as much as they describe the “how” in full technical detail.
Any architecture should enable its users to:
- Plan infrastructure, hardware, software and services procurement
- Organise how information and services are used
- Arrange the system components to function as an integrated whole
It’s important to develop Solution Architectures to a common set of design principles. Services Orientated Architecture Service (SOA) should be considered a strong candidate for this. A system based on a SOA will package functionality as a suite of interoperable services that can be used across the entire enterprise. Sub systems within an SOA interoperate through the use of communication methods based on industry-wide Web-service standards (e.g. SOAP). SOA can be used to guide design in each architectural domain as the overall solution design takes shape.
A schooling ICT system will have three main architectural “domains” – Software, Physical Infrastructure (hardware) and Information. The goal of SOA is to define architectures in terms of services. Each of these start at the conceptual level – i.e. the AFC mapping that we covered in Step 2 – before drilling down into logical and physical designs.
The conceptual architecture summarises the overall design from the perspective of the user; the logical architecture shows how services work; the physical architecture shows how the hardware is configured.
Here, AFCs are chunked into layers and groups that define what services stakeholders will receive, and where those services come from.
In the Logical Architecture, the Conceptual Architecture is re-drawn as a series of technical service layers and blocks with clear relationships:
The Physical Architecture sets out where the physical infrastructure components sit in relation to one another in order to deliver the services defined in the Logical Architecture:
The great thing about standards is that there are so many to choose from! Industry standards can certainly help simplification if they themselves are simple to deploy. Choosing standards that partners or vendors should adhere to can be a way of simplifying interfaces between organisational boundaries and simplifying interoperability.
There are many standards for IT as a whole and for a complete list I recommend “Enterprise Architecture at Work” by Marc Lankhorst et al., Springer. For the education domain, and for schooling in particular, there are a few standards, but their application in schooling solutions across the world is inconsistent to say the least – they often just get in the way.
Below is a sample of education relevant standards:
|Identity Management||Shibboleth, LDAP, Kerberos|
|Content Management||Metadata: IMS/IEEE LTSC Metadata & Dublin Core, IMS Content Packaging, IMS Digital Repositories|
|Data Management||SIF, ZIS, Metadata: IMS/IEEE LTSC Metadata & Dublin Core|
|Collaboration and Communication||IMS Enterprise Services, SIF, XML/Web Services|
|Business Process Integration||Business Process Execution Language for Web Services (BPEL4WS)|
|Learning Management||IMS Enterprise Services Web Services, SIF, XML/Web Services|
|Library Management/resource management||IMS Resource List interoperability, OpenURL, Z39.50;Z39.50, SRU/ SRW (mainstream search protocol), MARC 21bibliographic record format, DC (Dublin Core)|
|Assessment and Reporting||IMS Question & Test Spec|
|Staff and Student Management||IMS Learner Information, IMS Enterprise|
Of these, SCORM and SIF are the most widely used in schooling systems.
The golden rule of simplification when it comes to standards is to only apply them if there is a strong case clearly linked to a well-defined need.
5. Move to Next Maturity Level
What counts as a good SEA in the highest performing schooling systems in the world will be completely different to that of schooling systems taking their first steps towards using ICT. Naturally, schooling systems need to evolve, therefore it makes sense to think of SEA not as a static blueprint but rather a series of steps on a maturity continuum.
As discussed in earlier articles, there are four quite clear stages of schooling system maturity –
Often, entire technology categories – such as laptops or whiteboards – are seen as an end in themselves and are implemented without considering how they fit within the broader organisation. This, of course, just increases complexity. A better approach is to identify the current maturity level of your organisation, then analyse the steps that need to be taken to get to the next levels of maturity and use solution projects to get there.
Putting It All Together
To summarise, driving out complexity is about structuring ICT in terms of architectures and processes, and then applying models, methods and disciplines to solution development.
- The container for managing the sum total of the complexity of any large organisation is Enterprise Architecture, and the domain specific iteration of Enterprise Architecture for schooling is Schooling Enterprise Architecture (SEA).
- An SEA Governance Team needs to be responsible for directing system development policies. Policy should state “simplification” as a key design goal.
- Mapping the functions of the organisation using partitioning to decompose functions into Autonomous Functional Capabilities (AFCs) is a key next step.
- Further simplification can be achieved through rationalisation – which includes removing, consolidating and prioritising AFCs.
- The goal of developing schooling ICT systems is to progress along a maturity continuum comprising four distinct phases. This is achieved through running solution projects.
- Solution projects should be run through the MSF process
- Solutions are developed through designing Conceptual, Logical and Physical architectures and this should be guided by Services Orientated Architecture.
- Standards may have a role in some solutions projects, but should only be used where there is a clear need to do so.