Furthermore, a given organization has a finite capacity for managing sophistication and complexity, and a limited willingness to invest in the management costs and overheads that may be required to extract the full benefit from more powerful systems.
There are two agendas that each appear to address opposite sides of this situation. The first is the simplification agenda, advocated most persuasively by my friend Roger Sessions, which addresses the problem that most organizations and their support systems (including IT) are riddled with unnecessary complexity.
The second is the maturity agenda, which suggests that an organization can extract more benefit from certain systems and practices and technologies by becoming more sophisticated. Maturity models are typically arranged as a series of maturity levels, and should be derived (although I suspect many of them aren't) from a robust theory of organizational change and technology adoption.
There are some subtle and usually ignored issues in the interaction between these two agendas, but I don't want to go into these issues here. Instead, I want to point to a couple of critical questions
- how much complexity and power does a given enterprise need (requisite variety)
- how should this complexity and power be distributed and connected
The first question looks like a simple engineering question, which should be bread-and-butter for requirements engineers. The need for complexity and power is driven by some set of demands, together with an economic argument that links cost to value (possibly but not necessarily expressed in financial terms).
The second question is clearly an architectural question. Two things are intuitively obvious about the design of complex machines: not every component needs the same amount of power and complexity; however, some components need proportionality of power and complexity. (It doesn't make sense to put a massive engine in a tiny car, and a fast car needs more powerful brakes than a slow car.)
Power and complexity are higher-order examples of so-called non-functional requirements. Architects need to be able to reason about the composition and decomposition of non-functional requirements.
- Let P be some property of systems and components - say performance or quickness or reliability or security or throughput or whatever. If the components of a system have properties P(1) ... (Pn), what can we say about the composite property P of the whole system?
- Conversely, if we have a requirement for the whole system to have property P, what can we say about the properties P(1) ... (Pn) of each component?
The enterprise is a sociotechnical system, so I'm not just talking about technical components here. A racing car needs a driver whose reaction speeds are matched to the speed of the car, and a maintenance team capable of rapidly diagnosing and fixing all the minor technical problems that could occur during the race.
Similarly, an enterprise needs a set of management capabilities whose intelligence is matched (proportional) to the power and complexity of the operations and operational systems - thus we have an architectural view of the enterprise as an intelligent sociotechnical system, with an appropriate balance of power and complexity.
I don't want to hear that the complexity has been completely removed from the technical systems, because I then fear that the necessary complexity has been merely displaced onto the people inside the organization - or worse, onto the customers.
Conversely, I don't want to hear that the complexity has been completely embedded inside the technical systems, because I then don't trust the people inside the organization to fully manage this complexity.
What I want to hear is that there is just enough complexity and power in the technical systems AND at least enough intelligence in the human systems to manage this complexity and power properly. And I expect the enterprise architect to be responsible for maintaining this proper balance.
No comments:
Post a Comment