Such a topic could easily attract philosophical speculations. However, the intention here is to make a short and pragmatic walk within the territory that's common for this community. And I hope it will kick off some fruitful discussion.
Models in time
Let's review the all too familiar transformational tenet "AS-IS/TO-BE" with three aspects: reality, models and time. It will again be a model, inevitably a wrong one but hopefully a bit useful.
The release time T2 of a model of an existing object is normally equal or bigger compared to T1 - the modelled object's state time. Then based on that we normally[1] make several "COULD-BE" models. These are options related to future time Tn, created in T3 and T4 (see attached ADF - “time of the model”/”time of the real object state modelled”.) Of course the real object in T4 is probably different from how it looked in T1. It's good to have this in mind and do reality check from time to time to be sure that the projections are based on the right assumptions. Once confirmed that all COULD-BEs are based on solid grounds and look like viable options, they could be compared and tested through what-if exercises and simulations. Then we choose a "TO-BE" winner or make one combining the non-excluding strengths of the nominated COULD-BEs.
When this TO-BE (T4/Tn) is implemented, sometimes in stages, we have a real object in state Tn which is a transformation of the one from T1. If we model it, chances are the new AS-IS (Tn+1/Tn) will not look much like the TO-BE (T4/Tn).
Now let's see some examples of modelling time in ARIS.
Time-dependant look and position
One nice way to represent time is by changing the shape and position of on object symbol depending on time attributes. That's achieved in ARIS with attribute based modelling where an object occurrence take its place in the model based on some attribute representing point in time and the shape is changed to represent another, typically some kind of duration.
Clogged processes
ARIS Business Simulator can do wonders with simulating process behaviour based on many time attributes like processing, orientation and static wait time. One of the many benefits however is finding the process bottle necks, those places where the flow gets clogged. And the miracle KPI showing this is the dynamic wait time. It accounts for many things like resource availability, capacity, how the job is done and when.
Lost Time
Lean manufacturing focuses on eliminating various types of waste like transportation, waiting, overproduction, inventory and complexity. But then again it all comes down to lost time (and eventually money). The Value Stream Mapping, a proven technique, represents waste by turning overproduction or late production into times depending on customer demand. These times sum up to the process lead time (PLT). The time of value-added activities divided by PLT shows the process efficiency. We can test how different improvements like pulling and levelling can change that.
It's time to find the real cost
Processing time along with how many times a resource is used can show where the real overhead is compared to traditional costing methods. The process cost analysis in ARIS Business Optimiser calculates instantly the complex interrelation between structures and KPIs.
Many timelines together
We can imagine two, three dimensions and some of us probably a bit more. But that's all. The Process Support Map in ARIS IT Architect overcomes this modelling challenge by showing together timeline of many application systems in relation to the time of their support of particular process and in particular location.
Time recording
That’s probably more logical to start with than to end but anyway. Time recording recently appeared in Business Optimiser.
[1]The approach do first AS-IS then TO-BE is often criticized and sometimes rightfully. The intention here is not to promote it or discuss it. That could be a topic of another article.
ARIS model
Hi Ivo,
Frankly saying I struggle to follow your post, it seems to me that mixed up different questions around "time" in one single article.
Just for clarification - while speaking about "model" are you referring to ARIS diagrams which are in fact views or you are referring to architecture models (combination of artefacts, relationships between them and properties of artefacts and relationships) as per IEEE 1471?
One comment right away - Process Support Map has only one timeline and uses it to allocate application roll-out at certain organizational resource to support a certain capability or process (other artefacts are possible in headers of rows and columns). No alternatives are possible, so one timeline only.
/Konstantin
Konstantin,
Thank you for your comment. Yes, the term 'model' creates confusion as it means one thing as defined in UML, another in IEEE 1471 and a third in ARIS. I use it more in line with IEEE 1471 here as view can be changed without a change in the actual model depending on the aspects that need to be visualised.
Re: Process Support Map, it's a matter of convention as well. When visualising the lifecycle of a single application system, that's sometimes referred to as its timeline. So the ability to represent many lifecycles and view the planned or actual status of each system in one diagram was referred to in the post. I see you point, and of course, strictly speaking you are right.
Ivo,
thanks for the clarification. Do I understand you right that you propose to create separate models for each certain point in time?
Re: PSM: this viewpoint is not used for visualizing of a single application lifecycle, but for an applications roll-out and consolidation over enterprise.
/Konstantin
Konstantin,
The justification of creating as-is or future-state models depends on objectives and context and my intention was not to provide some prescription here, let alone an universal one. It was rather to initiate a discussion on the relations of lifecycle of business objects and models that attempt to represent some aspects of certain states of those objects, existing and planned.
Re: PSM, exactly. PSM shows the planned or actual state of (part of) the application portfolio (landscape) at once and thus being sort of what-if simulation tool and adds another (physical) dimension with process support units. This enables communication of different application system states depending on location and/or organisation unit.
I don't know what exactly created misunderstanding in relation with PSM but I'm happy for it as this second screen you put is something new to me. Is it some new functionality in ARIS IT Architect to generate project schedule (it looks like that) from the PSM data or?
Ivo,
unfortunately there is pretty much misunderstanding about PSM and its usage as an instrument for active roll-out planning. That is why I am trying to correct your statements to set proper expectations for readers of this thread later on.
Re: your last statement "This enables communication of different application system states depending on location and/or organisation unit." No, it does not. PSM focuses on application roll-out and does not cover application evaluation and acquision phases - other system states. Certainly, you may consider that part of the application lifecycle defined in AST attributes can be automatically calculated based on roll-out, production and phase-out states of application instances at ALL org. units for ALL business capabilities\processes. However I doubt practicality of such built-in dependency - at the end of the day there are different roles involved into ALM, APM, PPM and EAM. However an automatic or on-demand consistency check - no one plans a usage of an application after its decommisioning - could be definitely useful.
Please, note that PSM can show application fate (run, growth, transform or any other methodology) in form of colorful canvas, however, that is not an application state!
Re: models and time - I do not think that there is any value to have intermediate states like could-be1, could-be 2 until there is some change in the reality. Every model change should be the result of transformative project in the reality. And yes a compliance assessment comparing planned state with actual state after project completition (in terms of structure and properties of elements of architecture model) is ultimately necessary to understand the gap.
/Konstantin
Konstantin,
Yes, this clarification is important. However, I don't see it so much as about preventing wrong expectations than about setting conventions. "application fate" = "planned (or expected if you prefer) application state". But then again I understand why certain perception of "state" can lead to erroneous conclusions.
Please note the last question of my previous comment. I'm really curious about that.
Re: could-be. I agree but only to a certain extent. In many cases doing it could be a waste of time. But fully excluding it would mean writing off the benefits of what-if analysis and simulations. Those I've experienced many times (I admit: not as often as I wanted or expected to but still), and I'm not alone.
In many cases doing as-is could also be a waste of time and even detrimental to the adequate choice of to-be (see the footnote of the post for one such example).
If I am to propose an approach that would certainly be an adaptive one which might include or exclude any of the models shown in the diagram.
Ivo,
I would disagree with yout statement above: ""application fate" = "planned (or expected if you prefer) application state"." Fate of a resource is defined by an investment decision - are we going to invest into the resource and how much? 2 applications may be in production starting from 01.01.2010 but in one we decide to invest ("Grow") based on its improtance for critical business capabilities. The second applicaiton will in future still stay in production but we are going to keep investments on the low profile ("Run"). In both case the planned state is the same, but the fate is different.
Re: your question - no, this is not an OOTB functionality. At least, not yet.
Re: could-be. I assume there is some misunderstanding. What I question, is the necessity to create 2 COULD-BE as per your timeline above. Instead I would rather consider 2 alternative TO-BE and select one as a target for the transitonal project. Why do you need an intermediate state if there is one actual transformation only?
/Konstantin
Ivo,
I came across this article via the 'competition' for best post....I wish you well.
I am interested in the ARIS Business Simulator, and in particular have you any case studies or short examples of experience you would be able to publish? I work at Lanner who provides the simulation software inside ARIS, we would very much appreciate working with you to produce a paper or short article.
let me know if you are interested
Geoff
Geoff,
I think you did a wonderful job. Process simulation is generally undervalued. It's viewed as a daunting task with uncertain benefits. I think that perception has much to do with the choice of processes to be simulated and the perception of ARIS Business Simulator as a pure analytical tool. You gather lots of data, simulate and on seeing what causes i.e. bottlenecks, try to reduce them by changing resource usage, instantiation or process structure. That's true but that's not all. Indeed it's a very powerful analytical tool but it could be used a mile beyond the area of analytical tools (the so-called 'knowable domain'). Then the recognition of certain, not immediately evident patterns and cause-and-effect relationship could be - if not of direct use - at least insightful for solving complex problems.
- Ivo
