A lot of Enterprise Architects and business stakeholders always talk about "As-Is" and "To-Be" models. I understand the use of "As-Is", it is basically a term used to refer to the current state of Enterprise Architecture (or the state, good or bad of the enterprise or a specific business function/area), I just seem to have a bit of a problem with the term "To-Be" - by definition (and application), it demands that a static, predefined "ideal" state (usually centred around a preconceived solution) WILL be realised - my concern is that things change on a daily (sometimes even more frequent) basis in and enterprise ecosystem, so all you can really model are a few (we need some alternatives most of the time) "future desired" Enterprise Architecture states (based on business drivers, like strategy or change requirements).
The next problem with the "As-Is" and "To-Be" approach is that it assumes that it should not be a problem to just create a "roadmap" from the "As-Is" to the "To-Be". My experience leads me to to think that the "solution" that unfortunately usually pre-exist to the "To-Be" (the "To-Be" is usually crafted to incorporate the solution) can not be accurately and comprehensively defined (architected) or in compliance with the Enterprise Architecture (and other changes in progress or required) - can't you only really architect a solution if you know what it is that is required and how it will work/fit in, symbiotically, with everything else?
This is relevant to this topic, but will be explored a bit more later.
Is an enterprise not dynamic? Do things really just comply to an "optimally" structured model and then continue in equilibrium until such time as there is a active decision made to introduce change?
Looking at Enterprise Architecture from the point of view that the enterprise is in reality just another dynamic system,a business ecosystem (my preferred description), then we will need to shelve the ideas of static states (time-dates stamped) "As-Is" (opposed to a "current" (implying that evolution is accounted for up to the point of assessment or Enterprise Architecture consultation) and a static "To-Be" vs. a desired future state (it has a future time/date attached) that is not replacing evolution on hold - the dynamics continue, even if we have future plans!
This is very much lead by factoring in the concept of chaos theory (and dynamical systems), not that there is complete disorder, but that the Enterprise always have an element of uncertainty (associated with change), it exhibit apparent random and unrelated behaviour/impacts, but actually this dynamic system (the enterprise ecosystem) show deterministic behaviour through relationships of the components - thus seeking order and structure (See Chaos vs. Cosmos)
The next problem with the "As-Is" and "To-Be" approach is that it assumes that it should not be a problem to just create a "roadmap" from the "As-Is" to the "To-Be". My experience leads me to to think that the "solution" that unfortunately usually pre-exist to the "To-Be" (the "To-Be" is usually crafted to incorporate the solution) can not be accurately and comprehensively defined (architected) or in compliance with the Enterprise Architecture (and other changes in progress or required) - can't you only really architect a solution if you know what it is that is required and how it will work/fit in, symbiotically, with everything else?
This is relevant to this topic, but will be explored a bit more later.
Is an enterprise not dynamic? Do things really just comply to an "optimally" structured model and then continue in equilibrium until such time as there is a active decision made to introduce change?
Looking at Enterprise Architecture from the point of view that the enterprise is in reality just another dynamic system,a business ecosystem (my preferred description), then we will need to shelve the ideas of static states (time-dates stamped) "As-Is" (opposed to a "current" (implying that evolution is accounted for up to the point of assessment or Enterprise Architecture consultation) and a static "To-Be" vs. a desired future state (it has a future time/date attached) that is not replacing evolution on hold - the dynamics continue, even if we have future plans!
This is very much lead by factoring in the concept of chaos theory (and dynamical systems), not that there is complete disorder, but that the Enterprise always have an element of uncertainty (associated with change), it exhibit apparent random and unrelated behaviour/impacts, but actually this dynamic system (the enterprise ecosystem) show deterministic behaviour through relationships of the components - thus seeking order and structure (See Chaos vs. Cosmos)
To explain the view of the enterprise as an ecosystem will probably highlight the dynamic nature - there are a multitude of internal and external (value chain and market) components that all have an influence on the enterprise and also an impact on how all these components come together and co-exists in a symbiotic nature (if that is possible). Even though in constant flux (due to external market changes or internal evolution) the ecosystem components needs to be adjusted (introduced, eliminated, modified) and their relationships amended with the aim to achieve a stable as possible state to achieve the enterprise goals (nothing more than surviving and thriving) - Enterprise Architecture serves to record this stable/optimal (or most viable) state, providing the ability to discover change opportunities (issues, risks and improvements) and then to facilitate exploration of a dynamic environment (to drive the enterprise towards the optimal, stable state) to enable change to happen in a controlled manner (reducing the probability of fueling the chaos).
More to come from this topic on Solution Architecture...and "states" of Enterprise Architecture.
Posts
0 comments:
Post a Comment