“Simplicity” guru Roger Sessions met little resistance to his “simple” theory when he visited New Zealand last week — but putting simplicity into practice in IT is another matter, he says.
On the face of it, arguing for IT simplicity seems obvious, but Sessions says simplicity is almost never an overt objective of IT implementations or architecture design.
Sessions is working on his seventh book, tentatively titled Simple Architectures for Complex Enterprises. His aim is to control complexity by adding a theoretical background to the search for simplicity, he says.
The consultant and author was here for a series of briefings with local IT services firm Fronde and discussed his theories with two local CIOs. He found little disagreement.
“Complexity is getting in the way of delivering business-value from IT systems,” he says. It is primarily an issue of architecture.
Sessions says while it is common to hear about security or performance, or reliability, as IT goals, “we never hear people talking about complexity”. This is because people believe it is a natural by-product of functionality. “I don’t see it that way. I see it as a result of a lack of focus,” he says.
He says if systems are complex, it becomes very difficult to align them with the business. Security can always be added to a well-architected system, whereas complexity is the enemy of security, he says.
“Fundamentally, complexity is the major issue,” he says.
Sessions wants to create what he calls a “science of simplicity”, through the creation of mathematical models for what complexity is all about, and then use this to create and, most importantly, validate architectural solutions.
He says the architecture level is the right place to fight complexity, as this is where business-process and information systems meet. However, he adds that we don’t even know what it means to have a good architecture.
“In IT we do this all the time,” he says. “The first time we get to see if an architecture is any good is after we’ve spent a lot of money implementing it.” If there are two possible architectures that may meet a business’ needs, the best is the least complex, he says.
His ideas received a very sympathetic response from Mainfreight’s CIO, Kevin Drinkwater, and Aubrey Christmas, CIO of the Employers & Manufacturers Association.
Drinkwater says Mainfreight has seen first-hand, through its acquisitions, various organisations that have made their businesses very complex. The Owens Group is an example here, where JD Edwards was being implemented at considerable cost, he says. When Mainfreight took over, the business was migrated to Mainfreight’s system in six weeks, for around $25,000.
“We come at it from a simplicity point of view all the time,” he says. For Mainfreight, the acid test of complexity is, if a process can’t be completed manually it can’t be computerised or automated.
Consultants can also be a source of complexity — Owens had to get in consultants to “tell them about their own business”, says Drinkwater.
“You can form a complex view of what, in essence, is a simple process,” he warns.
Sessions agrees, adding it is in the consultant’s interest to make things complex. The search for simplicity is a cultural issue as much as a technical one, he says.
When it comes to projects, 80% of the benefit can often be realised for 20% of the cost, says Drinkwater. It is the search for that last 20% of benefit that accounts for 80% of the cost. Therefore, he says, when the 80% benefit has been achieved, companies should stop and look again, and ask themselves whether the remaining 20% is worth the extra cost. He adds that it is the last 20% that also introduces the complexity.
Sessions says it is an architect’s primary responsibility to make things as simple as possible, but attaining simplicity is not necessarily simple.
He says the physics concept of “entropy” is key to any discussion of complexity, equating complexity with disorder in a system. Entropy tends to increase in any system and energy has to be applied to maintain order. Sessions says sometimes IT has to push back when dealing with the business to fight complexity.
A great example of the failure of complexity is the National Programme for IT, the giant UK health project, he says. This will almost certainly go down as the biggest failure in IT history — probably in the next six months. A requirement in the project for vendor neutrality may have inadvertently introduced layers of unnecessary complexity, says Sessions.
However, complexity has increased exponentially for many organisations, says Fronde’s northern general manager, Steven Graham. Mergers and acquisitions introduce complexity, and so does new technology.
But Sessions says there is no justification for this.
“I don’t want to use any language at all that implies complexity is acceptable,” he says. One issue is that nobody “owns” complexity. It should be owned by the enterprise architect.
Sessions’ theory about managing, or rather fighting, complexity is, basically, the idea of “simple iterative partitions” that focus the mind on functionality, rather than complexity. He says he uses the term “partitions” in the mathematical sense, so partitions on their own won’t do the job, as there are multiple ways to partition any universe.
The test of whether “partitioning” has been undertaken correctly is through what Sessions calls “equivalence relationships” — tests that will show not just partitioning but whether these are the optimal partitions.