How best to model different architectures

[Mike Hemming]

We’re beginning to adopt TOGAF, Archimate and EA to describe our architecture models. I’d like to develop Contextual, Conceptual and Logical models that describe our Business, Application and Technical architectures. I’m unsure of two major issues.  
First, would it be best to have the Contextual, Conceptual and Logical models all in separate .eap files, or better to have all three in the same .eap file.  As we gate our architecture requests, not all models will be affected, so I lean to separate models, but will that complicate reuse.
Second, I think that Archimate advocates four high level packages, Viewpoints, Business, Application, and Technical Architectures. The Architectures packages contain repositories of the germane objects (application components, services, functions, etc) and I see these as each being in their own packages.  The viewpoints (like the Application Usage viewpoint) then are drawn using the objects in the repositories, presenting how the objects relate.  
I’m thinking I’d create the various objects in the appropriate packages in the repository, then place then on the diagrams I want to develop to show the particular viewpoint.
Is this how others approach this or am I way off base?
Thanks for your advice.

[Paolo F Cantoni]

Hi Mike,

FWIW, you're off to a good start separating the items in the repository from the diagrams (viewpoints) that render them to the outside world.

If you're doing this for an entire enterprise, then you'll also need to consider how to handle Current, Future (and perhaps even Past) states.

You'll also need to concern yourself with the overall enterprise view and the view of a set of one or more specific projects.

I'm currently revising my enterprise repository to accomplish something similar.

I'm looking at a hybrid solution, a conceptually unified repository, but manifest in a federated set of repositories.

HTH,
Paolo

[Sunshine]

Looks like a good start. I've found that separating the catalogs of elements from the views works best too.
Some things you may want to consider adding.

• Motivation
• Implementation and Migration
• Technical Debt
• Architecture Decisions

I put everything in one model with SQL server

[Paolo F Cantoni]

We’re beginning to adopt TOGAF, Archimate and EA to describe our architecture models. I’d like to develop Contextual, Conceptual and Logical models that describe our Business, Application and Technical architectures.
[SNIP]
[edit]My emphasis added...[/edit]

Why is it that most of the time the most important (and fundamental) architecture "Information" is ignored....    

(I AM a Data/Information Architect, after all)  

Paolo

[Mike Hemming]

Data/information architecture is contained within the Application Architecture - it's not ignored at all.  I was brought up with Data Modelling, ERDs and DFDs and understand well its fundamental importance.

We’re beginning to adopt TOGAF, Archimate and EA to describe our architecture models. I’d like to develop Contextual, Conceptual and Logical models that describe our Business, Application and Technical architectures.
[SNIP]
[edit]My emphasis added...[/edit]

Why is it that most of the time the most important (and fundamental) architecture "Information" is ignored....    

(I AM a Data/Information Architect, after all)  

Paolo

[Sam Courtney]

This link is to an EAP file that contains a TOGAF Repository Template - it could be helpful in setting up an initial model outline structure. We provide this as part of a course we offer for using EA with TOGAF.
http://www.aprocessgroup.com/myapg/architecture/apg-togaf-ea-repository-template-v2-0/
Let me know if you have questions!

[Paolo F Cantoni]

Data/information architecture is contained within the Application Architecture - it's not ignored at all.  I was brought up with Data Modelling, ERDs and DFDs and understand well its fundamental importance.
[SNIP]

Actually, in TOGAF, there are four architecture domains:
http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html
3.12 Architecture Domain

The architectural area being considered. There are four architecture domains within TOGAF: business, data, application, and technology.
------------------------
The data domain covers the data aspects of the other three domains.

There's another concept in TOGAF (which I can't put my finger on right now) that has 3 aspects whose names overlap with 3 of the four the architecture names - but leave out Data Architecture.

I WAS being facetious with my initial comment  , but there is that area of confusion where TOGAF says there are three of these, but four architectures (that cover the same universe of discourse).  It was confusing to me until I worked out TOGAF was talking about two different concepts.

Have a good weekend.

Paolo

[Rodrigo Nascimento]

I agree with Paolo's view that data domain (which I prefer to call Information Domain at Enterprise Level) covers data/information aspect of Business, Application and Technology domains. I wouldn't have it under Application Architecture as it may constrain the scope of your information architecture and minimise its important role in defining and communicating the semantics used across the organisation, and its support in linking Business, Application and Technology domains.

Regarding your first question, I would have all your models in the same repository (being .eap file or database) for a better discoverability and reusability. Sparx EA gives you a lot of flexibility to organise and maintain the models. We have been managing models at package level by using XMI exports/imports and Subversion to distribute releases and merge changes.

Another suggestion on the Information Modelling side, I would prefer to use UML and BPMN models rather than ERDs and DFDs, as the formers provide you a better alignment with the business (and the laters can be derived from them). Using UML for your logical models also betters support derivation for other physical models and technologies. I wrote a post with an example how to derive XML Schemas from an Enterprise Information Model:

http://goo.gl/P2OdJ (updated! sorry... I've put the wrong link before!)

It follows the OMG's MDA approach, which is supported by Sparx EA functionalities.

Hope it helps!

[Mike Hemming]

Thanks all.  Your right about the constrained view of the Data Architecture.  I never looked at it as supporting the BA,AA and TA.  As an aside, one notion that's gaining some traction here is taking a similar approach with a Security Architecture - i.e. it supports all three layers as well.  I can certainly see building blocks here and patterns depending on the level of security required.
I'll follow the advice and model all architectures in one eap.
For the modelling,  I agree with not using DFDs and ERDs.
We're using Archimate's approach, but we've also developed Use Cases, so I believe there's some redundancy.  Our client seems to be leaning towards Use Cases and the predominant tool for describing their business layer, so I may have some customising to do.

Thanks again to all.  Great help.  Feel better prepared to take the plunge!