Associate all elements to a phase in time

[spakendralo]

In order to be able to show an AS-IS, TO-BE, far-in-the-future-TO-BE, each element (Application, Interface, Functional Flow, etc.) should have some kind temporal properties: start and end.

It could be a start date and end date, but perhaps the dates should be more milestones and not real dates or there should be milestones that can be later related to dates.

In terms of requirements: As a designer, I need to show that a new element will appear, but the rest will remain ASIS. As a viewer, I need to check what is new in milestoneA, milestoneB, etc.

[mauvaisetroupe]

Start-date and end-date exists in different objects - see documentation here : https://mauvaisetroupe.github.io/ea-design-it/lifecycle/

I guess we could add:

• an additional attribute to give the status (in production, ...)
• and maybe a date of the last modification (could be useful for example to have the modification in the last year for regulatory report)

[spakendralo]

Good. So concerning the date, could we have some kind of slider when creating the view of landscapes and other views?

But also. We could inspire ourselves from Archimate 3, perhaps. See metadata at the end if the page https://pubs.opengroup.org/architecture/archimate3-doc/chap13.html#_Toc10045448 There is a "work package" element. You could for example assign something like InvestorProfileService to MIFIDII_Milestone1 package. The MIFIDII_Milestone1 package could have a date and therefore the startdate of an element could inherit this date? It would be cool - you would be able to see in which context the element has been put in place. Of course, InvestorProfileService would then change scope, so therefore this is a 1-N relationship. Perhaps it's a bit ambitious for now?

[mauvaisetroupe]

1. Do you think that this notion of work package is something additional (we keep start and end date on each object).

2. What about the idea of last-modification date? Is there a concept in Archimate that could support the concept? Adding it directly on the different entities? A work package should automatically update that date?

I feel that this notion of "time" is really essential and useful.

But I'm afraid of maintainability...

[spakendralo]

After checking Archimate there is no real concept of time such as an attribute. All is really done with elements, two of which are helpful:

• Deliverable: A deliverable represents a precisely-defined result of a work package.
• Plateau: A plateau represents a relatively stable state of the architecture that exists during a limited period of time. https://pubs.opengroup.org/architecture/archimate3-doc/chap13.html

I tried to run this on real life examples but IMO eventually these "plateaus" are only for project explanation purposes - not suitable for our viewpoint IMO. If we imagine a long running project: some elements are added sooner, some later, some are then adapted for other purposes, some are created in scope of incidents... So finally some elements are related to one or more Plateaus and some others are not. Not very useful for the "time travel" functionality, and I seriously question if it is interesting to know that a MifidProfile service has been added in scope of MIFID since things change and MifidProfile soon becomes InvestorProfile and then ClientProfile, etc. It is only interesting to know this when researching the MIFID project.

So finally:

1. StartDate and EndDate seem sufficient. It's like SCD2, we just need a calendar and update the query.
2. Modification date looks strange to me. If something has been modified, then it has to be modelled or else it is irrelevant. E.g. some new data is stored in master, this has to be modelled.
3. Plateau (or something like Major Milestone) seems to me not useful for our current viewpoint, so nothing new to add from Archimate.

Close ticket?

[mauvaisetroupe]

Imagine an unlikely situation: you develop and deploy a new application and new flows in 2020, but you use the new application in 2021. Imagine you need to report for regulatory reason new 2021 application...

How you query your database to detect such a case ?

You set a start date with xx/xx/2021 ? As an effective start date in production?

[mauvaisetroupe]

Other question, how you deal with the requirement : "I want to know applications and flows updated last year" ? A simple modifications log (with date and a short description) could give an interesting information concerning how you data repository is up to date, couldn't it?

[spakendralo]

Imagine an unlikely situation: you develop and deploy a new application and new flows in 2020, but you use the new application in 2021...

Good question...

Let's assume that you always want the architectural schema (designed) to match discovered flows and applications.

Case:

1. In 2019 you have a flow Account->CBS

2. In 2020 you still have Account->CBS but you decide to merge accounts and credit cards in one new service and you deployed Liabilities->CBS, only that Liabilities doesn't work yet

3. In 2021 you remove Account and Liabilities starts working.

I think we can conclude that this will only be possible if Account, Liabilities, and the two flows have the property of Start and End date. No modification date needed.

[spakendralo]

Other question, how you deal with the requirement : "I want to know applications and flows updated last year" ? A simple modifications log (with date and a short description) could give an interesting information concerning how you data repository is up to date, couldn't it?

I think that the reason why this is omitted from Archimate is that you can show these changes with elements. Here an example where I added some CreditCard capabilities to Liabilities service:

So perhaps if just these 2 data objects have a date, you can deduct a change. It is true, however, that the Liabilities element does not figure our immediately as an impact of the change.

[mauvaisetroupe]

Conclusion of our discussion

• We keep start & end date on different entities.
• We add a kind of "logging table" with date, description, that allow to have a historical view of modification on entities (applications mainly)
• we will see in the future if plateau or work package is an applicable concept