Multiple projects sharing/working on a common baseline

[Modesto Vega]

[SNIP]
Modesto needs to say what his context is.  I've been describing the usage I indicated.  If you are mainly software development based, your needs are different and a different structure and behaviour will apply.  Sparx is flexible enough as a platform to allow both modes to operate.

I’ll try to summarise the context, this organisation is not in the business of software development. In fact, we have an organisation

• With one of the largest Information Systems estates I have seen, in the thousands if various forms of grey IT is included
• Where the Information Systems estate 1) is full of old and venerable legacy applications, some of them bespoke and some COTS, and 2) is  only documented partially and to different standards
• Where most of the systems and applications in the estate were not and are not developed or implemented by the organisation itself but by suppliers (this is not a software development house)
• With a significant transformation programme where Cloud and COTS are preferred over other alternatives
• Which is part of what I describe as wider data exchange networks, involving other legal entities

Most of the above is largely outside our control.

From an architectural point of view we are not primarily interested in development but on managing how all of this interacts or will interact, and, because of the latter, on managing/governing/assuring the implementation and decommissioning of systems.

I have no problems with the concept of domains, how ever strictly you want to define them. Never had. We have 2 domain ontologies, one for non cross domains (more abstract) and another for cross-domains, with everything in the latter being an specialisation of the former. This all works fine, as it has done in the past, but starts creaking when projects and programmes come into the picture.

Something that we have started to consider is to use classifiers to solve some of the problems we have. I am not sure it is very orthodox from a UML point of view, because classified instances are objects and not classes, but it appears to solve one of our problems.

[Glassboy]

I hear you.  The problem with that sort of organisation is you struggle to get out of Zachman's top tier and formal methodologies (such as TOGAF) really just get in the way.  I've had some success using a stripped down UML palette to draw maps. 

[Paolo F Cantoni]

Early on in my career, I came across the following quote (possibly mangled by me - it was over 40 years ago). 
"The purpose of an information system is to allow the user to ask the same question of the system and reality - and get the same answer!"

^{Jean Raymond Abrial}

This has guided my professional efforts.  The repository is such an information system.  Consequently, I ask my audience what questions they want to be answered and then figure out what I need to do to allow them to answer it.  For most users, modelling isn't their "day job" so I try to make it as frictionless as possible to use (in this case Sparx EA).  I will incorporate stuff from many modelling technologies and try to consolidate things as much as possible.  Remember "copying from one is plagiarism, copying from five is research!"

Sparx EA almost gives me the flexibility to present things customised for different specific audiences.
I don't believe ANY standard can do the whole job, but like natural languages, researching and using more than one will help in understanding how to allow the system to provide the user with the answers they need.

I think this thread has come a long way and I've had a lot of things to think about while ingesting it.

I think, though, one basic difference between the software development repository and the organisational repository is that it is NOT possible to have one item per domain in an organisational repository.  We realised that early on and moved to separate the items from the diagrams.  The diagrams end up in any structure you like, and the appropriate items may appear on as many as required to tell the story.

Paolo

[Modesto Vega]

Just bringing some additional thoughts to this thread.

[SNIP]
I think, though, one basic difference between the software development repository and the organisational repository is that it is NOT possible to have one item per domain in an organisational repository.  We realised that early on and moved to separate the items from the diagrams.  The diagrams end up in any structure you like, and the appropriate items may appear on as many as required to tell the story.

As Paolo has correctly highlighted there are certain elements such as organisations where it is not possible to have one item per domain. In fact, I think there are other examples what I’ll rather not address them now.

The 2 other points I wanted to make are about: modelling the model, specifically modelling the package structure without creating it, and reducing (even eliminating) duplication via specialisation and correct naming.

Modelling the model
Generally speaking, I agree that to structure a repository, a domain/subject area approach is better than a type approach. However, assuming a domain/subject area has its own package (please don’t forget that a package in Sparx is an element), how do I go about modelling the model without creating the package structure? For instance using stereotyped classes to model the model, to represent the packages in the model without actually creating the folder structure. After all, this is what I would expect anybody doing enterprise architecture to do before jumping on doing any actual architecture work.

One other point, Sparx has the concepts of model and package. I pose that one of the difficulties I often encounter is when to use a package as a (sub) model and when to use it to group elements of a similar type.

Reducing or eliminating duplication through specialisation
Having spent time looking at our repository and needs, I have concluded that element duplication can be significantly reduced by using specialisation and proper naming.

This essentially involves creating hierarchies, effectively ontologies. Something I have no problems with but would appreciate some comments.

The other aspect of this is that in exceptional cases it may be better to use classifiers or structural nesting. There are 3 things I do not have clear:
1) Classifiers appear to be a form of specialisation, a ‘type of’ specialisation, but I cannot find in the Sparx EA documentation a list of the element types where classifiers are permitted.
2) I always thought that by using structural nesting I was setting the parent as the classifier of the child but this is not always the case
3) Lastly, what is the relationship between instantiating and classifiers. Creating an object as an instance of class sets the class as the classifier of the object. But this does not appear to apply to anything else - e.g., AFIK I cannot instantiate an actor or organisation [Note: thought UML wise this may sound semantically incorrect, it may not be as crazy as I read when I wrote this sentence.

[Geert Bellekens]

I'm pretty sure you can instantiate a (UML) Actor. Not sure what you mean by Organization (that doesn't exist in UML)

Geert

[Modesto Vega]

I'm pretty sure you can instantiate a (UML) Actor. Not sure what you mean by Organization (that doesn't exist in UML)

Geert

Thanks Geert - you are right, actors can be instantiated, an Organisation is an Actor with an MDG stereotype of “Organisation”.

However, Sparx doesn’t seem to set the classifier of the instantiated actor to the actor being instantiated. This is no a problem but would welcome clarification if this is by accident or by design, Sparx and/or UML.

[qwerty]

I seem to remember you can define the instance stereotype for an MDG element. Check _instanceOwner and _instanceType properties of the stereotype.

q.

[Paolo F Cantoni]

Hi Modesto,

I'm working on a more detailed response to your last post of the 23^rd; however, I just noticed the title of the thread.  As when I asked for clarification about your context, does the phrase: "Multiple projects sharing/working on a common baseline"  mean multiple project variants from a common baseline (such as one variant for iPhone, one for Android etc.).  Or, did you mean "multiple (separate) projects impacting against a common set of items" (as per your information system estates explanation of the 3^rd?

The answer may alter the tenor of my response.

Paolo

[Modesto Vega]

Hi Modesto,

I'm working on a more detailed response to your last post of the 23^rd; however, I just noticed the title of the thread.  As when I asked for clarification about your context, does the phrase: "Multiple projects sharing/working on a common baseline"  mean multiple project variants from a common baseline (such as one variant for iPhone, one for Android etc.).  Or, did you mean "multiple (separate) projects impacting against a common set of items" (as per your information system estates explanation of the 3^rd?

The answer may alter the tenor of my response.

Paolo

I mean the latter “multiple (separate) projects impacting against a common set of items”. We do not have a business requirement for the former.
In other words, we have multiple projects/initiatives trying to construct and develop a coherent enterprise architecture.
Looking forward to your more detailed reply.

[Paolo F Cantoni]

Thanks, Modesto,

Another question if I may.  You may have guessed that I use these discussions to refine my own ideas about modelling and then try to implement them in my MDGs.  So as I'm thinking about the reply to your post, I'm going through that process also.

I've created one of my rambling responses (which is not yet fit for publication) and I'm not satisfied with it, so I'd like to clarify how you see some things.

Am I correct in understanding that for your context, you are dealing with the relationships between specific systems, actors, processes etc.  Thus, leaving aside whether or not ArchiMate is "the greatest thing since sliced bread", you are dealing with ArchiMatey things, in an ArchiMatey way,  rather than UMLy things in a "UMLy" way?  Reiterating that you're looking to model the reality your business user encounter and not the software development paradigm they use to interact with it.  I know you've more (rather than less) said so    but I've put a slightly different slant on what you said, and I want to know if you're happy with that.

Paolo

[Modesto Vega]

Thanks, Modesto,

Another question if I may.  You may have guessed that I use these discussions to refine my own ideas about modelling and then try to implement them in my MDGs.  So as I'm thinking about the reply to your post, I'm going through that process also.

I've created one of my rambling responses (which is not yet fit for publication) and I'm not satisfied with it, so I'd like to clarify how you see some things.

Am I correct in understanding that for your context, you are dealing with the relationships between specific systems, actors, processes etc.  Thus, leaving aside whether or not ArchiMate is "the greatest thing since sliced bread", you are dealing with ArchiMatey things, in an ArchiMatey way,  rather than UMLy things in a "UMLy" way?  Reiterating that you're looking to model the reality your business user encounter and not the software development paradigm they use to interact with it.  I know you've more (rather than less) said so    but I've put a slightly different slant on what you said, and I want to know if you're happy with that.

Paolo

Thanks Paolo.

Yes, plus data and this is a key point. Data covers models and data integration, both intra and inter system. None of which can be graciously covered to the desired level of detail in ArchiMate.

In a nutshell, we are looking for a halfway house, so to speak, between ArchiMate and UML. Something that sounds and looks ArchiMatey for actors and processes, could sound ArchiMatey (but not necessarily) to model the model, and is a bit heavier/more detailed for systems and data.

Currently, my view is that ArchiMate requires too much heavy lifting for our current objectives.

We do not care about the software development paradigm (other than we are likely to be forced to go Agile). We care about modelling our business reality (as our users see it or should see it once user/stakeholder oversimplification is removed).

[Paolo F Cantoni]

Some definitions to start:
Modelling the Model

What do you mean by Type approach? I've been in similar organisations to you. We found that separating the objects from the viewpoints considerably eases the load.  The viewpoints are organised by domain/subject area, while the items are organised by type.

We also, from a conceptual viewpoint, changed our language, regarding packages.  We use the term Folder to mean a container in the model hierarchy.  Some folders contain other folders and therefore denote a branch.  The term package is used to denote a branch that is transportable (import/export.  A repository root is a top-level folder.  However, we also create "Namespace Roots" (at least conceptually) for branches that encompass a domain/subject area.  We use the Version field to (effectively) group things related to the same namespace root.

Sparx uses the term model self-inconsistently, so we avoid it.  We use the term repository to mean the physical container for the various root folders and their contents.

How do those sound?
Paolo

[Modesto Vega]

Thanks Paolo - very, very useful.

[SNIP]
Some definitions to start:
Modelling the Model
What do you mean by Type approach? I've been in similar organisations to you. We found that separating the objects from the viewpoints considerably eases the load.  The viewpoints are organised by domain/subject area, while the items are organised by type.

We have/had a repository organised as you described above. Roughly speaking we had: all behavioural elements in a folder with the related diagrams, and all structural items in another folder will all related diagrams. Both, the behavioural and structural folder branches were subdivided into subfolders - e.g., classes and class diagrams were kept in a separate subfolder from components and component diagrams. Please note that I have oversimplified but it gives you and idea.

Our original approach, as you described, was to create viewpoints from that structure for specific domains - such as People and Organisations or Locations - or a particular Subject Area - such as Customer Registration or Online Sales. This is where Sparx started to badly creak because, AFIK, there does not seem to be a way to a) collate all relevant elements without physically copying them (please correct me if I am wrong), and b) once they have been collated into viewpoints to allow multiple projects/users to collaboratively change them (through the viewpoints, not the original package structure).

In addition, we found 2 other nasty problems: 1) matrices using the type/discipline approach are huge and largely unusable, and 2) the documentation artefacts were so long and flat that getting them reviewed and published become a inordinately lengthy exercise.

The alternative is “to model the model”: 1) to identify which domains and subject areas are needed, 2) how they roughly interact with each other, 3) create a package - please read folder  and not model - for each one of them, and 4) breakdown each folder into behavioral structural folders in the way described above.

Domains are more abstract than subject areas. Domains (and certain subject areas) give us patterns. Subject areas intersect domains. When a subject area needs to use a domain element, it either consumes it as defined in the domain folder or specialises it with inherited attributes displayed in all class diagrams.

The only 2 exceptions are the organisational model and certain generic behavioural aspects which sit outside and above the “model of the model”, and domains which do not have a behavioural aspect.

At this point, I should say the to “model the model” we use stereotyped classes, using an MDG.

The resulting repository is no longer type/discipline centric but domain/subject area centric. As a result, it is very easily to give a group of users read/write access to specific domains/subject areas. With a type/discipline centric approach this becomes a challenge.

[SNIP]
We use the term Folder to mean a container in the model hierarchy.  Some folders contain other folders and therefore denote a branch.
[..]
The term package is used to denote a branch that is transportable.
[...]
A repository root is a top-level folder.

With both structures, we tried to differentiate between model packages, which are easily transportable or baselineable, and folder packages which give structure to the models.
I find that the domain/subject area centric approach is more model friendly, more transportable, than the type/discipline centric approach. Without viewpoints, a type/discipline centric approach does not result on easily transportable or baselineable model packages; in our case they are simply too big.

[SNIP]
However, we also create "Namespace Roots" (at least conceptually) for branches that encompass a domain/subject area.  We use the Version field to (effectively) group things related to the same namespace root.

Could you please expand?

[SNIP]
Sparx uses the term model self-inconsistently, so we avoid it.  We use the term repository to mean the physical container for the various root folders and their contents.

I have noticed and find it mildly annoying. Sparx EA appears to force its users to use the Sparxian concept of a model immediately below the root and, out of the box (without an MDG), does not allow intermediate structural folders in between. Also the Sparxian concept of a model is type/centric and I would have less of a problem with it if I could put package folders (read place holders in between)

Incidentally, it occurs to me that the Sparxian concept of a model is not very enterprisey, it is more suited for project work. Not that we will stop using Sparx for enterprise architecture.

[Paolo F Cantoni]

Thanks, Modesto,

A lot to think about there!  It will take time to reply.  One question I have though is to try to better understand your access process.  What kinds of roles need to access specific branches?  In our repository, we principally had Enterprise level Architects and solution (project), specific users. Our Enterprise users had (pretty much) unfettered access to the Enterprise branches and project users had write access only to their projects.

What is your equivalent usage?

Paolo

[Modesto Vega]

Thanks, Modesto,

A lot to think about there!  It will take time to reply.  One question I have though is to try to better understand your access process.  What kinds of roles need to access specific branches?  In our repository, we principally had Enterprise level Architects and solution (project), specific users. Our Enterprise users had (pretty much) unfettered access to the Enterprise branches and project users had write access only to their projects.

What is your equivalent usage?

Paolo

We have Enterprise users (including architects) and solution/project users (including architects). We have many more of the later than the former. The later do not want to have to work with a full repository (either a copy or from an RDBMS repository) as per the previous structure, this is because it is too big, I sympathise with that. Besides, the previous repository is such a mammoth that it is not easy to share, the transportable units are too big.

Enterprise users, specially architects, can do pretty much anything in the repository. Other users have some features restricted such as Stereotype Creation, Transforms, Creation of Documentation Templates, Project Transfer, Scripts an so on.