As I was reading Roger Sessions’ latest white paper, “The Thirteen Laws of Highly Complex IT Systems”, Laws 1 and 2 immediately caught my eye:
Law 1. There are three categories of complexity: business, architectural and implementation.
Law 2. The three categories of complexity are largely independent of each other.
That complexity in these categories can vary independently (e.g. complex business processes can be designed and implemented simply just as simple processes can be designed and implemented in an extremely complex manner) is important to the understanding of complexity in IT. Likewise, it serves to remind that the function of the architecture and implementation of a system can vary independently from the underlying business process(es) it was intended to enable. That variance is an insidious form of technical debt, whether it occurs over time or was a foundational aspect of the system. In either case (though perhaps more so in the latter), customer satisfaction is going to be negatively affected.
Poor customer service, particularly in the form of ignoring (or being perceived as ignoring) the needs of the business, is a prime trigger for rogue IT implementations. The uncoordinated nature of these implementations leads to an overly complex “accidental architecture”. These accidental architectures pose problems not only in that they tend to be fragmented and more expensive than a well-designed solution, but also in that their existence constrains future architectures. Structure follows strategy when building anew, but then strategy will find itself constrained by structure.
The antithesis of this IT dystopia is the “fluid enterprise”, described by Brenda Michelson as one where “…assets in our portfolios are no longer sole-purposed applications or databases; they are also potential multiuse components and triggers to be exploited in the new architecture”. In order to evolve applications that come together as an enterprise platform, it is necessary to start from a base of applications that meet the needs of their users. While rationalizing a collection of shadow IT components is likely to be a long and expensive task, that does not mean that gluing together a bunch of inadequate (albeit “official”) systems will be a better solution.
Form Follows Function 
Nice job as usual Gene.
Single purpose capabilities, whether applications or databases take on a life of their own and devolve into silos.
OTOH, integration is a pretty difficult thing to achieve. Two forms of integration need to be considered, each with their own challenges:
1) Platforms and frameworks (like Android, for instance) provide leverage by implementing the common aspects across problem spaces. However, a naive focus on commonality leads to being painted into a corner. To succeed, this approach must first understand what varies across these spaces and find strategies to manage the variations.
2) Interoperability is a more loosely-coupled approach that focuses on well-defined interfaces and protocols. Because this approach permits each party to have its own separate implementation, it *seems* easier. However, the challenge here comes in 3 places:
a) common message semantics (did party A understand B). Look at HL7 for medical interoperability to see how screwed up this can become.
b) clear interaction contracts (when I say X what will you do? what happens if you can’t?)
c) clear, shared workflow models (who’s driving and who’s navigating?)
And when the number of parties that can interoperate goes up, this approach inherits the same commonality and variability problem faced by Platforms and Frameworks, but often without the authority and governance to enforce order.
I’ve just been burned by both of these strategies too many times to treat either as a panacea. That’s not to say that I think they are bad paths. I see them as double black diamond ski slopes that claim novice skiiers as victims.
Charlie
LikeLike
Thanks, Charlie.
With platforms and frameworks, the more general purpose they are, the harder they are to architect. Architecting an application to provide services to the enterprise as a whole is no trivial task, but far easier than an OS.
Likewise with interoperability. The more generic the usage intended, the harder it is to get right (if it’s even possible to do so – I think the RESTafarians are experiencing that special despair that comes from seeing a style of architecture perverted because it’s pervertable – freedom isn’t free). I haven’t had the “pleasure” of working with EDI or HL7, but I have had to deal with a “standard” canonical data models. I use the CDM technique within ESB implementations and love it there. As a lingua franca across enterprises, not so much.
I like the ski slope metaphor!
LikeLike
Pingback: Legacy Systems – Constraints, Conflicts, and Customers | Iasa Global