 My name is Sonia Gonzalez, I'm the architect to an archimede farm director for the open group and I have also been working along with Bill in the harmonization project which is looking to harmonize a ton of an archimede and we have a series of white papers so I'm going to make some questions to Bill and we're going to have a chat about the project right now. Bill, please. My name is Bill Ostrom, president of Metaplexi Associates and Sonia and I have been working together for the past little over two years I think to try and make togaaf and archimede work better together from a practitioner's point of view and now we've published our first set of results and for phase one of the project and so we'll talk about things related to how well the standards work together in terms of your terminology, the modeling views and viewpoints as well as the fundamental definition of the terms that are used and the entities and their relationships. So the talk of an archimede both are open group standards, they have been developing in different paths because they are addressing different needs and concerns and as a general approach what would you suggest to final users to use the two of them successfully? Well I think you have to use the archimede language in order to describe your architectures and you do that as part of overall enterprise architecture process and so the togaaf standards are designed to allow you to have a method that you can follow as well as a framework for the content that you develop and so I think archimede provides that content and there needs to be some consistency between the two and again as you pointed out they were developed in different time frames by different people so there are some natural differences that occur but I think largely those can be overcome with some careful planning in terms of how you do the architecture modeling and how you set up your content framework. Both of them have different set of concepts and like you said togaaf is a framework so it's bigger, larger than archimede, archimede has fewer concepts but some concepts are like similar some others have some differences so for example in this case you're trying to harmonize concepts and glossaries between togaaf and archimede do you think it's worth to take just the whole togaaf glossaries in this larger to the archimede one that just takes some some of the points the touch points that both standards have? Well I think from an architecture practice point of view the more you can standardize your terminology in general the better off you're going to be the more consistency there is between the practitioners the less likely you're going to have confusion but then when you get down to the specifics of developing architecture descriptions using consistent terminology is important so yeah one of the things that we've done in project harmony is to basically look at all the glossary the terminology that's in the glossaries of both togaaf and archimede and see where they're the same and places where they're different and then suggest alternatives that might be able to help people to develop a consistent glossary in terms for their own organization I think that's the really important thing here is that each organization really needs to kind of figure that out for themselves some organizations will really do a very good job of a very detailed implementation of togaaf and they'll use archimede and great detail and others will be maybe a little bit less orthodox a little bit more casual and so the degree of harmonization that they need that might be a little bit less I think you also have to look at the operating model of the company to understand you know the level of rigor that's needed in order to standardize these terms so you can integrate different parts of the organization and make them work together yeah also every organization has some glossary so at the end it's like my glossary and I do it to harmonize that with both standards at the end of the day is that this is like with the screen delivery value to my organization on the other hand we have the content meta model from togaaf but it's like they said like a framework for making enterprise architecture so where practitioners are making or starting making enterprise architecture they got into the content meta model and they have this issue okay how I'm going to fit this set of entities and relationship for actually delivering models and deliver architecture descriptions and then on the other hand we have archimede meta model which is different even though some terms and some relationships are similar they are different than the ones in toga what kind of advice or approach we do the liver to find and use it to overcome that well I think again a lot of that depends on the organization and the level of maturity that they have and I think it also depends a lot on the types of tooling that they're using to develop the models and the repositories that are using the store of content so that there needs to be an agreement just like there needs to be a standardization of the glossaries of terms there needs to be a standardization of the entities that are used to create the artifacts that you're using to describe the architecture and then also the relationships between those entities and so that's the stuff that we've been doing with with the project harmony is looking at those relationships between the entities as well as the entities themselves and how they need to be similar or they're related because you have to harmonize glossaries then you come up with the content with the elements the entities and then you have to harmonize the relationship between them so everything is related and that comes to the last question about viewpoints I mean in toga we have a set of viewpoints some users say that it's too general to high level and also our company has a set of viewpoints which is larger than the one in toga and it's like more focused because it's like a language notation and model notation but if we're going we're trying to address stakeholder concerns what would you do with these viewpoints would you touch that point how do you solve that issue I first have to figure out the equivalency what kind of equivalency is there already between what uses for viewpoints and what is required to get sometimes the names are different and they're really describing the same things other times there's actually some semantic differences between what one the what the argument language requires and what to get provides so again it all boils back to your organization's needs so maybe able to just take the few points that you need and not worry about trying to make everything so we'd like to see we'd like to see you be able to use our commit to describe pretty much any artifact or any of the toga artifacts but we're not you know I think it's really important to remember that what we're trying to do here is make these two stands work together but we're not trying to integrate them together you know like weld them together so that they cannot be used anything else we want to see our committee useful for other other enterprise architecture frameworks and we want to see toga be able to use other your tools like you about modeling tools and things like that and also regarding viewpoints and it will depend on what your stakeholder concerns also there could be a specific viewpoints that could be a combination of several viewpoints that's always yes yeah that should always be the basis that you use for making decisions about the viewpoints so thank you very much for sharing your opinions with us and let's move forward with the second phase of the program okay thank you very much yeah thank you so much