Random Thoughts‎ > ‎

Controlling the enterprise (IT) architecture

posted Feb 27, 2012, 2:55 PM by Alar Raabe   [ updated Feb 27, 2012, 3:10 PM ]
We can control/develop enterprise (IT) architecture by following:
  • using Conway's law -- enterprise organization should be designed such that we would like the enterpise IT architecture to become -- there must always exist an interested party for developing certain architecture feature/element (e.g. developing the architecture in certain way must be in somebody's interest);
  • limiting the resources in suitable manner would stimulate thinking and (as a consequence) reduction of complexity, increase of reuse, and simplification of maintenance -- that is architecture can be developed by the owner/steward of necessary resources -- in case we have a governance body for architecture like architecture committee, it must own or command resources;
  • ownership of main (architectural) principles by top management (they must belong to the enterprise identity and value system) -- only then they will influence the architectural decisions;
  • differentiated actions according to the governance model:
    • in the enterprises with strong central governance (power) it is possible to design the architecture accordin to certain goals, and the result would be foreseeable,
    • but in the enterprises with weak central governance (power) or completely decentralized enterprises it would only be possible to create favorable situation for architecture to emerge and develop (grow), and the result would not be foreseeable nor guaranteed;
  • differentiated capital investments -- the part of the architecture, which function is most static (i.e. infrastructure/platform) could afford the biggest capital investments -- to stay long time without changes it must perfrom very generic functions (as an opposite to the frequently changing parts of the architecture which could perfrom very specific functions) -- the more variable/volatile is the function, the smaller should be the capital investments;
  • limit the amount of "technical debt" allowed for the IT architecture -- large technical debt limits the options of change and "takes over" control of the architecture.