I am working with Bursatec, the technology company of the Mexican stock exchange on the architecture design for a new system. Bursatec is using the SEI’s Attribute-Driven Design (ADD) method embedded in a Team Software Process (TSP) environment for designing the new system. They also use the tool “Enterprise Architect” for documenting the system’s software architecture.
Last week, when working with Bursatec’s architecture team, they showed a nice little rule they implemented for using the design tool. Since I believe that many architects have the same problem when using a design tool, I thought it would be worthwhile sharing their solution. Continue reading
Maybe you have been wondering what you have to do as an architect of a software-reliant system to get ready for an SEI Architecture Tradeoff Analysis Method (ATAM) architecture evaluation. Maybe, like me, you hate to be taken by surprise and want to know the outcome of the ATAM upfront. Hmmmm … so, you too are thinking about a strategy on how to “game the system,” right? Well, here is how I do it.
First of all, let us accept the fact that nobody can build an architecture without weaknesses. We just don’t get enough time, money, or the right technology to do a perfect job. And of course, the ATAM will uncover all those weaknesses. If you get a well-trained ATAM team you can be assured that they will find most of those weaknesses. You cannot hide anything from them. So, don’t even try.
Posted in Architecture-Centric Engineering, Architecture-Centric Practices
Tagged architecture design, architecture evaluation, architecture review, Architecture Tradeoff Analysis Method, ATAM, non-functional requirements, SEI, software architecture, software architecture evaluation, software architecture requirements, software architecture review, software development, Software Engineering Institute, system architecture
Just heard the very interesting keynote from Zachman at the conference, and there is one thought I cannot get out of my mind.
The Zachman framework is about architecting the enterprise in terms of What?, How?, Where?, Who?, When?, and Why? from several different perspectives, such as the owners, architects, engineers, etc.
I see several similarities that software architecture tries to answer, therefore would it make sense to use the Zachman framework for software only products? I could see for example to structure the architecture documentation in this way. It might help to easily extract the information needed for the different stakeholders, such as the management, the developers, etc.
Any one with experience in this topic? Any thoughts?
- Felix Bachmann, SEI