Sparx Systems Forum

Enterprise Architect => General Board => Topic started by: HLidstrom on August 13, 2019, 10:51:06 pm

Title: Pros and Cons of mixing TOGAF and Archimate?
Post by: HLidstrom on August 13, 2019, 10:51:06 pm
I have some experience using Sparx for UML modeling, but I am rusty. I have worked quite a lot adapting Enterprise Architecture for different organization needs and tools. The organization I work for now has already made the decision to follow TOGAF ADM and use the ArchiMate notation (mostly). My task at hand is to draft the rules that will ensure consistency in our Sparx EA modeling. To that end:

Where do I find documents describing the TOGAF and ArchiMate metamodels, as implemented in Sparx EA? That is, descriptions of element types with their attributes and descriptions of which relationship types can be used (are recommended) between which element types?

Can anybody share pros and cons of mixing TOGAF and ArchiMate types in the same model? E.g., Architecture Principles. Both TOGAF and ArchiMate have a Principle type. I should stick to one. The TOGAF type has attributes (tagged values) for rationale and implications in addition to name and description (which is all the ArchiMate type has) I am tempted to use the TOGAF type, but will that come back to bite me later, in a mostly ArchiMate model?

Any insights would be much appreciated.
Håkan Lidström
Title: Re: Pros and Cons of mixing TOGAF and Archimate?
Post by: Glassboy on August 14, 2019, 07:33:30 am
Hi Håkan, you'll be fine modelling TOGAF with the ArchiMate notation.  What you need to look at first is actually the TOGAF content meta-model.  If you organize your elements according to the content meta model it all works out.
Title: Re: Pros and Cons of mixing TOGAF and Archimate?
Post by: Sunshine on August 14, 2019, 10:50:51 am
After spending over a decade using UML I started my career as an Enterprise architect using TOGAF but found as it didn't have a formal language just a lifecycle, metamodel along with some guidelines, I adopted ArchiMate way back in 2007 to do the modelling. It had the advantage of being simple and connecting business processes with applications and infrastructure. Looking back that was a good choice as its now a well established standard for enterprise architecture.
The descriptions of the elements can be found in Archimate V3.01 of the specification C179 from the open group. However it does not define attributes. By default Sparx EA provide
Which provide a good start however not quite enough for all elements to do proper Enterprise Architecture so I've added more attributes through tag values via a custom MDG. For example for the "application component" I've added
I've since had a look at the TOGAF MDG and found it too complex with an unrecognised notation.

I've got a pretty simple approach to EA now

I hardly refer to TOGAF now.
If you are interested in using TOGAF with ArchiMate there are set of documents written by the Open Group and called "Harmony" that provide guidance. I think it might be a bit dated as it referred to Archimate V1.0 but there is some good pointers. There is even a webinar. https://publications.opengroup.org/catalogsearch/result/?q=harmony (https://publications.opengroup.org/catalogsearch/result/?q=harmony)

Hope that helps. Good luck on your journey
Title: Re: Pros and Cons of mixing TOGAF and Archimate?
Post by: Richard Freggi on August 14, 2019, 12:49:00 pm
TOGAF explicitly says it is notation - agnostic and is compatible with UML, Archimate and others.  No issues!
Title: Re: Pros and Cons of mixing TOGAF and Archimate?
Post by: HLidstrom on August 14, 2019, 11:19:22 pm
Thanks all for your replies. I'm really not looking for a discussion about the pros and cons of  TOGAF and ArchiMate as such. That choice has already been made for me.
 I need insights on hands-on modeling in Sparx, using a mix of the ArchiMate and TOGAF types provided in the TOGAF MDG. Yes, TOGAF is a method and ArchiMate is a notation. But when I install the TOGAF MDG I get a TOGAF perspective that provides a set of element types, i.e., a notation. I also get an ArchiMate perspective that provides another set, i.e., the ArchiMate notation. There is overlap between these notations, e.g., the type Perspective that I mentioned in my original post.
 
Another example. There is a TOGAF type "OrganizationUnit". There is also an ArchiMate type "Actor" that can be used to model active structure elements, such as, organization units. Will it matter later on which I use? Will I be restricted to one set of organization relationships if I choose OrganizationUnit and another if I choose Actor? Or, it really doesn't matter because when it comes down to it both are actually stereotypes of Class and I can associate any way I want?

I know Actor comes with a nice shape to show on diagrams and OrganizationUnit just shows as a plain Class box, but I'm not worried about that at the moment. I worry about getting the underlying information structure right. About being able to capture EA information in a way that can be reported on in a format that will give the proper information to decision makers. Keeping in mind that different decisions will require different sub-sets of EA model data.

Any insights on the practical implications of mixing the notations in Sparx EA?
Title: Re: Pros and Cons of mixing TOGAF and Archimate?
Post by: Geert Bellekens on August 14, 2019, 11:26:09 pm
Hi,

Using the TOGAF framework with the ArchiMate notation is pretty much a common practice.

In terms of notation, I would try to stick as close as possible to the standard notation.

What we see often is that different areas in the model use different notations, often

- Architecture -> ArchiMate
- Business Processes -> BPMN
- Functional/Technical analyses -> UML

Also very often the standard notation falls short and is extended with organization specific properties.
If done right this is done using UML profiles and MDG technologies.
Also the links between the different notation are (for obvious reasons) non standard and can be added by an organisation specific MDG.

Geert
Title: Re: Pros and Cons of mixing TOGAF and Archimate?
Post by: Richard Freggi on August 15, 2019, 12:33:02 am
Hi,

Using the TOGAF framework with the ArchiMate notation is pretty much a common practice.

In terms of notation, I would try to stick as close as possible to the standard notation.

What we see often is that different areas in the model use different notations, often

- Architecture -> ArchiMate
- Business Processes -> BPMN
- Functional/Technical analyses -> UML

Also very often the standard notation falls short and is extended with organization specific properties.
If done right this is done using UML profiles and MDG technologies.
Also the links between the different notation are (for obvious reasons) non standard and can be added by an organisation specific MDG.

Geert

Just a side comment for the sake of talking and sharing here. Not trying to make a point of anything.
Mixing notations for different levels of architecture (conceptual, logical, physical) is a common practice and a cause of many errors and misunderstandings.
What I have seen working reliably in my experience is

- Architecture -> Conceptual level UML use case, class, package views
- Business Processes -> BPMN Conceptual (logical if needed) -> UML sequence diagrams
- Functional/Technical analyses -> UML -> Logical level UML sequence, class and component diagrams

There is a huge benefit in clarity, accuracy and efficiency in using the same notation and same elements for all architectural levels.

My experience is that Archimate could kinda sorta work but it lacks class diagram / data modeling which is critical for process/system harmonization and robust taxonomy/semantics; also Archimate does not have a robust metamodel which supports model extensibility and scalability as well as UML. 

Getting off my soap box now, sorry for the inconvenience.
Title: Re: Pros and Cons of mixing TOGAF and Archimate?
Post by: HLidstrom on August 15, 2019, 06:58:55 am
Thanks to all for the input. It seems I should not worry too much about mixing element types from different perspectives (if that is the proper Sparx term to use here), as long as I and my team mates do it consistently.
Title: Re: Pros and Cons of mixing TOGAF and Archimate?
Post by: Paolo F Cantoni on August 15, 2019, 08:41:46 am
Thanks to all for the input. It seems I should not worry too much about mixing element types from different perspectives (if that is the proper Sparx term to use here), as long as I and my teammates do it consistently.
Yes, Håkan,

You are absolutely right!  "It is better to be consistently wrong than inconsistently wrong".  I'm not expressing judgement here, it's just one of my aphorisms.  Consistency is what counts!  (see my tag)

When considering the example you provided, I have previously expressed the problem as trying to make one item when the different modelling technologies suggest you need to have more than one.  If you consider a specific instance of an Organisation Unit ("Office of the CEO") it IS (structurally) an organisation unit but it behaves as an Actor.  So my advice would be to create an Organisation Unit and recognise it can also be used as an Actor and be used is the place of an Actor where appropriate.

I have written some stuff on the "Agent as Actor in a Role" paradigm in recent posts.  They may be of use to you.

HTH,
Paolo

PS: Manage Complexity,
   .   .   Reduce Ambiguity,
   .   .   .   .   Eliminate Inconsistency!
TM

Is what we try to do with our modelling...
Title: Re: Pros and Cons of mixing TOGAF and Archimate?
Post by: Sunshine on August 15, 2019, 10:13:15 am
...
 I need insights on hands-on modeling in Sparx, using a mix of the ArchiMate and TOGAF types provided in the TOGAF MDG. Yes, TOGAF is a method and ArchiMate is a notation. But when I install the TOGAF MDG I get a TOGAF perspective that provides a set of element types, i.e., a notation. I also get an ArchiMate perspective that provides another set, i.e., the ArchiMate notation. There is overlap between these notations, e.g., the type Perspective that I mentioned in my original post.
Similar to what Geert has mentioned I use a mix of Archimate, BPMN and UML for different levels of abstraction. I chose these as they are standard notations. The TOGAF MDG whilst useful for TOGAF practitioners is not standard notation and therefore has limited literature to help use it.
- Enterprise Architecture -> ArchiMate for those high level elements
- Business Process details -> BPMN (elaborates on the Archimate Process with swimlanes and activities)
- Detailed Design -> UML ( Class diagrams, state diagrams, detailed deployment diagrams etc)

Try not to duplicate the same thing in different notations as it becomes an overhead to maintain.

Another example. There is a TOGAF type "OrganizationUnit". There is also an ArchiMate type "Actor" that can be used to model active structure elements, such as, organization units. Will it matter later on which I use? Will I be restricted to one set of organization relationships if I choose OrganizationUnit and another if I choose Actor? Or, it really doesn't matter because when it comes down to it both are actually stereotypes of Class and I can associate any way I want?
I know Actor comes with a nice shape to show on diagrams and OrganizationUnit just shows as a plain Class box, but I'm not worried about that at the moment. I worry about getting the underlying information structure right. About being able to capture EA information in a way that can be reported on in a format that will give the proper information to decision makers. Keeping in mind that different decisions will require different sub-sets of EA model data.

Any insights on the practical implications of mixing the notations in Sparx EA?

I'd suggest just use either the TOGAF MDG or the three mentioned above. If you decide after a period of time you want to change you can run a script to change the types. Like I said before the TOGAF MDG has non-standard notation and so literature is limited on how to use it. On the other hand the TOGAF MDG has attributes on some of those elements that may be useful.

Don't over think it just do some modelling in your preferred option (you know you have one) and see how it works out.

Title: Re: Pros and Cons of mixing TOGAF and Archimate?
Post by: Modesto Vega on August 20, 2019, 04:04:07 am
[..]  If you consider a specific instance of an Organisation Unit ("Office of the CEO") it IS (structurally) an organisation unit but it behaves as an Actor.  So my advice would be to create an Organisation Unit and recognise it can also be used as an Actor and be used is the place of an Actor where appropriate.

I have written some stuff on the "Agent as Actor in a Role" paradigm in recent posts.  They may be of use to you.
Organisational Units and Organisation are indeed Actors in a similar way as people and systems. A common problem with a framework like TOGAF or modelling languages like ArchiMate, UML or BPMN is that they do are not capable of supporting all of the modelling nuances.

I find TOGAF, not necessarily the Sparx EA TOGAF MDG, more extensible than ArchiMate or BPMN. I would not dare to try extending ArchiMate or BPMN.

What I have seen working reliably in my experience is

- Architecture -> Conceptual level UML use case, class, package views
- Business Processes -> BPMN Conceptual (logical if needed) -> UML sequence diagrams
- Functional/Technical analyses -> UML -> Logical level UML sequence, class and component diagrams
In terms of notation, I would try to stick as close as possible to the standard notation.

What we see often is that different areas in the model use different notations, often

- Architecture -> ArchiMate
- Business Processes -> BPMN
- Functional/Technical analyses -> UML
Not entirely sure I agree with this, it depends on what you mean with architecture. My experience is that, if you mean enterprise architecture, I prefer to use UML rather than ArchiMate, because UML is easier to extend (note the emphasis). The biggest 3 problems I have with ArchiMate for architecture are:
Title: Re: Pros and Cons of mixing TOGAF and Archimate?
Post by: Sunshine on August 20, 2019, 02:18:51 pm
Not entirely sure I agree with this, it depends on what you mean with architecture. My experience is that, if you mean enterprise architecture, I prefer to use UML rather than ArchiMate, because UML is easier to extend (note the emphasis).
The advantage of using ArchiMate over UML for Enterprise Architecture is that you don't need to extended it as its all as done for you. :) No point in making work for your self aye?
Quote
The biggest 3 problems I have with ArchiMate for architecture are:
  • It does not support Organisations, Organisational Units and Organisational (or Data Exchange) Networks
Not a problem as Organisations, Organisational Units are supported, if you read the literature you'll see they map on to business actor. Data exchange is modelled as flow. Business interactions can be used to model relationships between behavioural elements and Business Collaborations can be used to model relationships between structural elements.
Quote
  • It does not model Information System and interactions between very well. In fact, it does no have the concept of Information System
Again if you read the literature you'll see Information System Service is modelled as an application service and the logical and physical information systems are modelled as an Application Components.  Application Interactions and Collaborations are there too incase you were wondering.
Quote
  • The Business Object is insufficient to make any serious attempt at creating an Enterprise Conceptual Data Model
Enterprise Conceptual data models can be easily modelled with groups and business objects. Granted when you do a logical data model or physical data model and need to define attributes then of course UML is better, however Sparx EA does allow you to add attributes to ArchiMate Business and Application Objects and you can see these by disabling the shapescript on the diagram. I prefer data modelling with UML.
Title: Re: Pros and Cons of mixing TOGAF and Archimate?
Post by: Modesto Vega on August 22, 2019, 10:32:00 pm
Not entirely sure I agree with this, it depends on what you mean with architecture. My experience is that, if you mean enterprise architecture, I prefer to use UML rather than ArchiMate, because UML is easier to extend (note the emphasis).
The advantage of using ArchiMate over UML for Enterprise Architecture is that you don't need to extended it as its all as done for you. :) No point in making work for your self aye?
Quote
The biggest 3 problems I have with ArchiMate for architecture are:
  • It does not support Organisations, Organisational Units and Organisational (or Data Exchange) Networks
Not a problem as Organisations, Organisational Units are supported, if you read the literature you'll see they map on to business actor. Data exchange is modelled as flow. Business interactions can be used to model relationships between behavioural elements and Business Collaborations can be used to model relationships between structural elements.
Quote
  • It does not model Information System and interactions between very well. In fact, it does no have the concept of Information System
Again if you read the literature you'll see Information System Service is modelled as an application service and the logical and physical information systems are modelled as an Application Components.  Application Interactions and Collaborations are there too incase you were wondering.
Quote
  • The Business Object is insufficient to make any serious attempt at creating an Enterprise Conceptual Data Model
Enterprise Conceptual data models can be easily modelled with groups and business objects. Granted when you do a logical data model or physical data model and need to define attributes then of course UML is better, however Sparx EA does allow you to add attributes to ArchiMate Business and Application Objects and you can see these by disabling the shapescript on the diagram. I prefer data modelling with UML.

Sunshine, you are obviously a modelling language polyglot capable of translating from one language/framework to another. This is excellent but may I suggest you may have missed the point.

Of course you can model Organisations and Organisational Units as Business Actors, Conceptual Data Entities as Business Objects, Information Systems as Applications Services, Logical & Physical Systems as Application Components. But you have just given me a translation and I think a lot information has been lost in the translation.

My point is that ArchiMate has a number of vocabulary limitations some of which TOGAF does not have. Those vocabulary limitations can only bypassed through (explained) translations. Sometimes is better to talk a more suitable language, specifically if certain nuances need to be captured.

Edit 23 August 2019: If ArchiMate were a modelling language language short of terms, I would have less of a problem. But ArchiMate is a term rich language and I find very interesting/telling which terms have been left out, either by accident or intentionally.
Title: Re: Pros and Cons of mixing TOGAF and Archimate?
Post by: Sunshine on August 27, 2019, 07:46:40 am
Sunshine, you are obviously a modelling language polyglot capable of translating from one language/framework to another. This is excellent but may I suggest you may have missed the point.
Thanks for the complement being a ployglot but I'll agree to disagree with you on missing the point.
Quote
Of course you can model Organisations and Organisational Units as Business Actors, Conceptual Data Entities as Business Objects, Information Systems as Applications Services, Logical & Physical Systems as Application Components. But you have just given me a translation and I think a lot information has been lost in the translation.

My point is that ArchiMate has a number of vocabulary limitations some of which TOGAF does not have. Those vocabulary limitations can only bypassed through (explained) translations. Sometimes is better to talk a more suitable language, specifically if certain nuances need to be captured.
Again tend to disagree regarding information loss in translation. At the end of the day I think you'll find that TOGAF has limits in the real world too, the biggest show stopper is the lack of a notation.  The other is that those terms used by TOGAF aren't necessarily recognised by business or IT folk so there is translation to fit in the constraints of TOGAF terminology. Granted I think the TOGAF terminology is in some cases better that ArchiMate. The Open Group recognised this short fall in TOGAF and so put a lot of effort into harmonising ArchiMate and TOGAF and it looked like they may combine the two at one stage but I think they ran out of steam.
The fact of the matter is that TOGAF has a content meta model that whilst useful lacks a notation. So when you draw a diagram there is no defined shapes what a business unit looks like. Thus how do you know what that shape represents? Yes Sparx Systems has represented the TOGAF meta model with shapes but they aren't standardised so not necessarily good for communicating with someone who doesn't have Sparx EA.

If you look at other disciplines in building architecture or engineering they all have defined notations which clarifies what things mean on a diagram. Why do they do this? Well so that the person receiving the information in diagram form can accurately interpret it.

In the ideal world I'd like to see ArchiMate Notation meta model elements better named to match TOGAF element types that way we'd all be happy. For now I'm using ArchiMate until something better comes along. Been waiting for 12 years now :(

BTW: I created my own version of ArchiMate MDG with extensions and attributes that aren't available in the standard ArchiMate 3 MDG because it wasn't up to the job of doing Enterprise Architecture properly. Found the same with the TOGAF MDG but between the two TOGAF was slightly better. Sounds to me like your more comfortable with TOGAF anyway so just stick with that.

Title: Re: Pros and Cons of mixing TOGAF and Archimate?
Post by: Glassboy on August 27, 2019, 08:31:14 am
At the end of the day I think you'll find that TOGAF has limits in the real world too, the biggest show stopper is the lack of a notation.

Well the biggest show stopper is it creates a business for talking about doing IT, when most businesses want people just to get on and support the business that earns the revenue :-)
Title: Re: Pros and Cons of mixing TOGAF and Archimate?
Post by: timoc on August 27, 2019, 05:59:44 pm
At the end of the day I think you'll find that TOGAF has limits in the real world too, the biggest show stopper is the lack of a notation.

Well the biggest show stopper is it creates a business for talking about doing IT, when most businesses want people just to get on and support the business that earns the revenue :-)
In my opinion, TOGAF adoption is usually taken up by people who see their IT (and its evolution) as critical to generating revenue and supporting business functions. Archimate is best used to communicate the need (to invest in IT changes) with those people in the organization who do not :)
Title: Re: Pros and Cons of mixing TOGAF and Archimate?
Post by: adepreter on August 27, 2019, 09:04:20 pm
Indeed it is the same problem everywhere.
http://www.labnaf.one/ln-content/edu/EDU%2020%20Challenges.pdf

An alternative is having one single language that makes sense i.e.
- that is based on precise systems semantics
http://www.labnaf.one/guidance/index.html?guid=6A67F237-E1E4-41a2-BF3E-F922E1B18FF8

- and that is designed to support the complete process of driving transformations (the TOGAF ADM is a process for driving one single change)
http://www.labnaf.one/guidance/index.html?guid=1FC5C565-4DA7-4e0c-AD58-134E8BEC0CA5

For more information please contact Sparx Europe.
Title: Re: Pros and Cons of mixing TOGAF and Archimate?
Post by: Modesto Vega on August 28, 2019, 03:59:11 am
At the end of the day I think you'll find that TOGAF has limits in the real world too, the biggest show stopper is the lack of a notation.

Well the biggest show stopper is it creates a business for talking about doing IT, when most businesses want people just to get on and support the business that earns the revenue :-)
Couldn’t say it better. Glassboy is spot on here.

Again tend to disagree regarding information loss in translation.
Modelling languages have the same weaknesses and strengths as natural languages. With natural languages, lots of information is lost in translation and you need translators to ensure minimum loss of information and absence of conflict, conflict covers anything from open warfare to brawls. Of course, you only know this if you have the fortune or misfortune of knowing more than once natural language.

The only advantage that modelling languages have over natural languages is that if you know what to express I can choose an appropriate modelling language for it. This is not so easily done with natural languages.

Although I like the rigour of ArchiMate, I am not sure it would be my first choice because of the size of the vocabulary and its grammar. ArchiMate, in my opinion, requires a specialist, most organisations do not have one and often do not hire one when they decide to use ArchiMate.
Title: Re: Pros and Cons of mixing TOGAF and Archimate?
Post by: qwerty on August 28, 2019, 07:34:53 am
Although I like the rigour of ArchiMate, I am not sure it would be my first choice because of the size of the vocabulary and its grammar. ArchiMate, in my opinion, requires a specialist, most organisations do not have one and often do not hire one when they decide to use ArchiMate.
Yep. That goes for any language. The "funniest" I've seen when hiring Indian consultants speaking English with German customers to model some business (they are probably not specialists for) in UML. Translating thoughts being stored in so many brains and not written down is how many industries work. All of a sudden some people get the idea to have that documented in some way. So they come up with a technical language. The problem: their business guys having that business knowledge don't speak the technical language. Only their own dialect which is sort of their mother language with technical idioms. It's a hell of work to translate that. And yes: the translators are they key persons. But which of them can you trust? Is the cloud in the business guys brain the same (or mostly matching) the one in the UML model?

q.
Title: Re: Pros and Cons of mixing TOGAF and Archimate?
Post by: Glassboy on August 28, 2019, 09:16:37 am
At the end of the day I think you'll find that TOGAF has limits in the real world too, the biggest show stopper is the lack of a notation.

Well the biggest show stopper is it creates a business for talking about doing IT, when most businesses want people just to get on and support the business that earns the revenue :-)
In my opinion, TOGAF adoption is usually taken up by people who see their IT (and its evolution) as critical to generating revenue and supporting business functions.

Yeah that's what they normally say :-)  A lot of talking and not much walking.
Title: Re: Pros and Cons of mixing TOGAF and Archimate?
Post by: timoc on August 28, 2019, 06:25:37 pm
At the end of the day I think you'll find that TOGAF has limits in the real world too, the biggest show stopper is the lack of a notation.

Well the biggest show stopper is it creates a business for talking about doing IT, when most businesses want people just to get on and support the business that earns the revenue :-)
In my opinion, TOGAF adoption is usually taken up by people who see their IT (and its evolution) as critical to generating revenue and supporting business functions.

Yeah that's what they normally say :-)  A lot of talking and not much walking.
Yeh. its one thing to have a sponsor say "Lets do TOGAF!", it's another entirely to get an organizational to change. I call it organizational inertia (that it wants to continue in its existing state of rest or motion in current direction) :)
Title: Re: Pros and Cons of mixing TOGAF and Archimate?
Post by: Glassboy on August 29, 2019, 08:22:04 am
Yeh. its one thing to have a sponsor say "Lets do TOGAF!", it's another entirely to get an organizational to change. I call it organizational inertia (that it wants to continue in its existing state of rest or motion in current direction) :)

Yes there is organizational intertia, but there are also a lot of Enterprise Architects who are the poster children for the Peter Principal and very few Architecture group managers who are fully vested in change.
Title: Re: Pros and Cons of mixing TOGAF and Archimate?
Post by: Paolo F Cantoni on August 29, 2019, 09:00:13 am
Yeh. it's one thing to have a sponsor say "Let's do TOGAF!", it's another entirely to get an organizational to change. I call it organizational inertia (that it wants to continue in its existing state of rest or motion in current direction) :)

Yes, there is organizational inertia, but there are also a lot of Enterprise Architects who are the poster children for the Peter Principal and very few Architecture group managers who are fully vested in change.
(my emphasis)  "In titulo, ergo sum"?

Paolo
Title: Re: Pros and Cons of mixing TOGAF and Archimate?
Post by: Glassboy on August 29, 2019, 10:23:38 am
Some would say I'm displaying my bias against a certain other profession.
Title: Re: Pros and Cons of mixing TOGAF and Archimate?
Post by: Modesto Vega on August 29, 2019, 05:29:36 pm
Yeh. it's one thing to have a sponsor say "Let's do TOGAF!", it's another entirely to get an organizational to change. I call it organizational inertia (that it wants to continue in its existing state of rest or motion in current direction) :)

Yes, there is organizational inertia, but there are also a lot of Enterprise Architects who are the poster children for the Peter Principal and very few Architecture group managers who are fully vested in change.
(my emphasis)  "In titulo, ergo sum"?

Paolo
And a lot of enterprise architects must be doing/using the latest (....) - please fill the blanks - without first gaining mastery/proficiency. We used to call this “bleeding edge technology”, nowadays we seem to have gone beyond the “bleeding edge”. The “10,000 hour rule” is so often overlooked, proficiency is not a pill you buy over the counter and shallow.

Gladwell calculated that reaching the 10,000-Hour Rule is simply a matter of practicing a specific task and can be accomplished with 20 hours of work a week for 10 years.