Announcement: First meeting of the IASA-RJ study groups

The first official meeting of the IASA-RJ study groups will be happening on Thursday, March 26 from 7 to 9 PM. The idea is to eventually be running (at least) three self-organizing study groups separately. But for this first meeting, and until we decide that we have enough interest for each, we will try to touch on all three topics:

  • A study of the ATAM methodology for evaluating software architectures
  • Study and preparation for The Open Group’s ITAC certification for IT Architects
  • Study of The Open Group Architecture Framework (TOGAF) and preparation for those that want certification

That’s a lot to cover in a single meeting, and a very ambitious undertaking for a single study group. In this first get-together I will be giving an overview of the ATAM, and Marcelo Sávio will present the other two topics. Time permitting, we will then get down to business and discuss how we can organize the study group(s) and where to go from here.

If you’re interested in learning more about any of these topics, and happen to live in the Rio de Janeiro area, let me know. I’ll be happy to provide full information regarding the location of the meeting. Also, space is limited, so the sooner you let me know, the better. Lastly, if you are not yet a member of the IASA-RJ group, go to the Google Groups site and request permission to join, or send me your email and I’ll be happy to oblige.

Hope to see you soon!


2 Responses to Announcement: First meeting of the IASA-RJ study groups

  1. Sujay Ghosh says:

    Hi Timothy ,

    I would like to know the advantages / disadvantages of choosing an architecture framewok

    There is ZIFA, ATAM, TOGAF and many more doing the rounds.

    How do we choose from the multitude which is the correct architecture


    • Timothy High says:

      Good question, and unfortunately, one for which I don’t have a good answer (especially since I’m currently not well-versed in the world of enterprise architecture frameworks). ATAM isn’t a framework, just a workshop-style method for quickly evaluating an architecture and reducing some of the biggest risks. For the others, you have to choose them the way you would choose any process, methodology, or even tool or software package: look at your requirements, and try to find a best match.

      * Look to see what’s specified in the framework, and if it seems to provide support throughout your architecture process
      * Look for industry adoption and support – the more “popular” a framework, the more likely you are to find a common language with architects outside of your company; the easier it will be to find and hire people skilled in the framework; the more likely you will be able to use your knowledge outside of your current place of employment
      * Look for support in terms of artifacts, templates, and so on. The more busy work the framework does for you, the more it gets off your plate, the better
      * Look for adaptability. No two companies are alike, so you’ll want to be able to tailor the framework to your needs without the framework maintenance itself becoming a burden, and without losing its essence, without making yourself incompatible with the tools provided with the framework
      * Look for tool support. I have no idea which frameworks are most supported, but I know that there are a lot of “governance” and “enterprise architecture” tools being released out there, most of which have an underlying framework in mind.

      The original Zachman framework wasn’t actually a framework, but a taxonomy. It was a simple method by which you could organize your architectural artifacts, and make sure that you had covered all perspectives and needs. TOGAF evolved from Zachman (and other prior works – you should see the nutty, convoluted TOGAF family tree that was presented at our meeting!) as a full-fledged EA framework, and is the one with which I’m most familiar. Zachman, AFAIK, is mostly concerned with the communication of an (enterprise) architecture, whereas TOGAF is concerned with the iterative cycle of going from a business architecture to the technical architecture to implementation and back, all the while promoting reuse and improving your repositories of business requirements and capabilities.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: