Book a Demo

Author Topic: Togaf MDG Guidance  (Read 4077 times)

Taz4444

  • EA Novice
  • *
  • Posts: 4
  • Karma: +0/-0
    • View Profile
Togaf MDG Guidance
« on: June 01, 2011, 02:08:19 pm »
First post and new to Enterprise Architect and the TOGAF MDG so here goes:

Are there any documents or reference material that describes how to setup Enterprise Architect using TOGAF MDG where there is a central repository and many projects leveraging the continuum and SIB?  I am looking for details on how this would typically be setup when an organization has many projects that need to leverage common artifacts for the enterprise repository in Enterprise Architect.

Any guidance or recommendations would be greatly appreciated.

Thanks!

Thelonius

  • EA User
  • **
  • Posts: 274
  • Karma: +6/-0
  • I think. Therefore I get paid.
    • View Profile
Re: Togaf MDG Guidance
« Reply #1 on: June 01, 2011, 10:25:18 pm »
Hi Taz

You mean by 'leveraging' - those project simply need to view the Continuum and SIB to confirm information?

Or update?

Jon

Taz4444

  • EA Novice
  • *
  • Posts: 4
  • Karma: +0/-0
    • View Profile
Re: Togaf MDG Guidance
« Reply #2 on: June 04, 2011, 08:59:29 am »
Hi Jon,

One of the things I am trying to do is use the TOGAF MDG for Enterprise Architect to help me get my enterprise architecture practice established in my organization.  Right now I do not have a centralized location for architecture assets and every project seems to recreate the same thing (usually inconsistently and sometimes even incorrectly).  I am trying to understand what guidance is out there to setup an enterprise architect repository for use of common architecture artefacts and to understand how a project would reuse the models and diagrams (read but also update if they need to) and "publish" the changes back into a central repository for the enterprise.  In this way I would have a central location for all models and diagram and could start to improve my reporting and governance pieces as they relate to enterprise architecture.

Hopefully this makes sense...

Thanks,

Taz
« Last Edit: June 04, 2011, 09:00:16 am by Rfrasz »

Thelonius

  • EA User
  • **
  • Posts: 274
  • Karma: +6/-0
  • I think. Therefore I get paid.
    • View Profile
Re: Togaf MDG Guidance
« Reply #3 on: June 04, 2011, 11:25:49 am »
Mate!

It makes perfectly good sense.

You are in the same situation that I've been in many times over the last 15 years.

However. Let me ask you two questions:

1) Has your organisation decided to move toward consistent / common adoption of an architecture framework and method? Eg, the usual suspects: Zachman, TOGAF 9, DoDAF, FEAF, PEAF, etc.

2) Have you defined an architecture meta model?

3) What's your situation regarding Architecture Governance with respect to projects? Are the projects going to be responsible for defining "architecture" at the project level - in the absence of guidance from an "enterprise" architecture function? Or will the EA function define baseline and target capability / solution architectures at a high level, which are then delegated to one or more implementation projects?

You have a perfectly viable vision for what you want to do.

A lot of "lights" came on for me professionally about 3 years ago when I started to investigate the above areas. Combined with a few professional opportunities that I was lucky to be part of, working with a team of talented architects who wanted to achieve the same thing I wanted - we got there.

But prior to that point, I struggled.

You may recognise the language above as being "TOGAF 9".

Your responses to my questions above will determine the course of the conversation that follows, so I'll wait to hear more about your circumstances before making off-the-cuff recommendations. :-)

Jon

Taz4444

  • EA Novice
  • *
  • Posts: 4
  • Karma: +0/-0
    • View Profile
Re: Togaf MDG Guidance
« Reply #4 on: June 04, 2011, 03:25:10 pm »
Hi Jon,

I knew I wouldn't be alone as this is a fairly common problem.  Hopefully I can learn from your experience to get things moving the right direction.  Here are some details for your questions:

1) My organization has definitely decided to use TOGAF 9 as our architecture framework.  One of my goals is to establish the practice and I am starting with an initial iteration through the ADM to setup the repository and standard base which will be used as the foundation for other architecture work within my organization.

2) If what you are referring to is a classification model like Archimate 2.0 then yes my thoughts are to use Archimate 2.0.

3) At this point I am engaged in the architecture governance and have a team of 4 architects that I can assign to projects for governance and oversight.  In the future once the practice is established I would see other project resources producing architecture work with oversight from my team in the form of an architecture review board.  This makes good sense to further establish the EA practice and mentor others on the importance of architecture and planning.

Hope this helps.  Again, I really appreciate your assistance and feedback.  Looking forward to your thoughts and suggestions.

Taz


Thelonius

  • EA User
  • **
  • Posts: 274
  • Karma: +6/-0
  • I think. Therefore I get paid.
    • View Profile
Re: Togaf MDG Guidance
« Reply #5 on: June 05, 2011, 07:32:44 pm »
Taz

It's good that your organisation has adopted TOGAF as a common reference model for architecture definition and management. Although what this means in practice seems to vary from one organisation to another.

It would be good to know what kind of business context you're working in. For example, if your organisation is developing software applications for external customers, this may require a slight refocus of language.

But - assuming you're in a "traditional" corporate business context:

Are you concerned with Enterprise Business Architecture? Has your team - as Enterprise Architects - created a view of the organisation's business value chain > business function (decomposed) > key business processes (with value metrics, time, KPIs, "points of pain", etc)? If so - have these views been reviewed by all senior business stakeholders to the degree that those business stakeholders have assumed full "ownership" of those views?

Is your focus truly "the enterprise"? Or are you working within a "segment" (business domain)? Or are you within a program / project ecosystem?

The ArchiMate meta model is fine. I get by with the TOGAF MM, and a few extensions. I also omit a few entities. When modelling, I don't use all the ArchiMate "relationships", even though I know how. "Association" is the only relationship I need. I just need to know there is a direct dependency between two things. The dependency chain of "derived relationships" is more important. Sparx doesn't generate that information for you automatically, so you will be extending Sparx with your own code to do this (and other stuff, like reporting). I don't have time for coding any more.

Sparx allows you to publish your content to HTML. I'd be doing that for the SIB. Publish as much as you can to the "architecture" area of your corporate portal. There should be a governance process for changing standards. Governance is something you will facilitate.

Projects (and anyone else for that matter) should be able to easily access the SIB information. Requiring people to fire up Sparx to view the SIB is an impedance and suggests focus may be on project-embedded solution architects. Dunno.

What kind of questions are people asking you to answer? These questions will determine what you need to capture into your architecture repository (and the entities you need in your meta model). If no one's asking any questions - leave it out. But you need to look to the future, of course, and anticipate the obvious "next" line of questions.

Just because you 'can' model things doesn't mean you 'should'. ArchiMate was intended as a graphical language for "Enterprise Architecture", but it seems to be getting used by many people as a "new UML".

Questions like:

"How many business applications does 'this' business application define an interface to?"
"How many bus apps support 'this' bus process?"
"How many bus processes support 'this' bus function?"
"How many bus apps use Oracle v.11 as the data base?"
"How many different message-oriented middleware products do we use?"

But not: "How much are we spending on ...?" - ABC and TCO information is managed elsewhere.

Sparx is not really an 'enterprise architecture' tool or repository, in the full sense of that phrase as it has played out in the market over the last five years. Sparx is a good application / data architecture tool. It "can" be used as a professional-grade EA tool / repository, but this requires extending the app with your own code. If you're happy with that, and you know what you're doing, your professional diligence, focus and stick-it-iveness will bring you success. (I have used it this way myself, successfully...)

Good architecture isn't expensive. Good governance doesn't slow us down.

Happy to keep talking if we're heading in the right direction ... but we may want to consider moving the thread to one of the many LinkedIn groups where we talk about these kinds of things ... Sparxs' bulletin board makes my brain hurt ...

:-)
« Last Edit: June 05, 2011, 07:34:46 pm by jmcleod »

Thelonius

  • EA User
  • **
  • Posts: 274
  • Karma: +6/-0
  • I think. Therefore I get paid.
    • View Profile
Re: Togaf MDG Guidance
« Reply #6 on: June 05, 2011, 08:59:31 pm »
Forgot to mention - if you're using the Sparx ArchiMate MM - Sparx does not differentiate between 'service' at three levels (bus / app / tech) as defined in the ArchiMate spec. Sparx gives you a single plain vanilla 'service'. You have to know what you're doing when you define instances at the different levels. I'd be using stereotypes.

Also, the TOGAF MM is good at differentiating 'logical' and 'physical' concepts / entities. ArchiMate MM can be a bit confusing in this area.

For defining your SIB - the definitions of concepts in the 'tech' layer of the ArchiMate MM are all _very_ physical.

But your SIB naturally defines a taxonomy for technologies. In TOGAF, there are logical Architecture Building Blocks (ABBs) and physical Solution Building Blocks (SBBs), but the ArchiMate MM doesn't really make clear how to do this.

ArchiMate seems to have been created primarily as a 'modelling language' rather than as a 'meta model' to be used as a schema for defining an architecture repository that sits on an RDBMS.

I'm not very interested in the conceptual niceness of diagrams - I need to use the repository as a tool for rapidly answering business questions relating to architecture. This typically falls under the heading of "impact analysis".

The question being: "If we changed 'this' - what is dependent on it that we need to know about?"

Taz4444

  • EA Novice
  • *
  • Posts: 4
  • Karma: +0/-0
    • View Profile
Re: Togaf MDG Guidance
« Reply #7 on: June 08, 2011, 10:18:21 pm »
Thanks for the advice and input Jon.  I agree with your comments on coding as I would like to avoid it as much as possible.  I am going to spend some more time working with the TOGAF MDG and Enterprise Architect to see how I am going to set this up.  I have found some options for training in this space and am pursuing those as well.

Thanks again for all your help and guidance - very much appreciated!

Taz