Our Articles

A Monthly Article from our Speakers

Current Article of the month

Articles of 2014

Articles of 2013

Articles of 2012

Articles of 2011

Articles of 2010

Articles of 2009

Articles of 2008

Articles of 2007

Articles of 2006

Articles of 2005

Articles of 2004

Articles of 2003

Articles of 2002

Mike Rosen Ten Things an Architect Does to Add Value

by Mike Rosen

September 2009

 

"This article is based on a Business and Enterprise Architecture Email Advisor and is reprinted with permission from Cutter Consortium www.cutter.com"

Last year in a trip to Italy, I gave a talk at a Model Driven Architecture conference in Milan in a building that was 500+ years old. Originally built as a palace, it has subsequently been used as armament storage, hospital, home for orphan girls, school, who knows what else, and now as a conference center and hotel.
When confronted with comparisons between IT architecture and buildings, we often shrug them off by rationalizing that building are not designed to change, but software systems undergo constant upgrades and evolution. Yet this building has withstood major changes in use and huge upgrades in infrastructure, including the addition of heating, plumbing, electricity, and broadband. Wouldn’t it have been easier to just rip it down and start over? Well apparently not. The value and longevity of the underlying structure are such that it has continually been upgraded, and will probably continue to see upgrades for another 500 years. Putting this in relation to its lifetime we can draw a comparison to systems today. It’s as though a 25 year old CICS application were upgraded to an n-tiered, RIA powered, SOA structured, J2EE application in the last 3-5 years.
Clearly there are drastic differences between these two examples, but in each case, the underlying system had fundamental value even as other aspects of the system experienced dramatic changes. The strength, durability, size, location, and aesthetics of the building in Milan demanded that it be fitted for different purposes, in widely different environments. In comparison, what is the fundamental value of the legacy application? Is it the infrastructure, platform, user interface, code, servers? Probably not. What about the business rules and logic? How about the data models?
Next it was off to Rome where 500 years is young for a building. The Pantheon is still wonderfully intact after 2000 years, but more impressive to me is the Colosseum, also 2000 years old. Designed to seat 50,000-80,000 spectators with an elaborate system of portals (entrances / exits), it could be emptied of people in 10 minutes. Its design is still the basis for sports arenas today. Eliptical, 189 x 156 meters, 4 or 5 levels, and up to 48 meters high, each individual segment of the structure has an arched portal built using angled, multi-ton blocks of travertine limestone, capped with a central keystone. The keystone is still used in construction today. You can’t help but be impressed with the architecture, design and implementation of the building, especially considering the (lack of) technology available at the time.
So, what lessons could we learn from the Colosseum that might be applicable to today’s systems? Well, for one, there are fundamental principles that apply to all system designs. Good ideas and successful patterns of design and implementation are timeless. History has provided an excellent filter on architecture. Only the really good structures are still standing, the rest have fallen down for one reason or another. And these building can provides us with some valuable lessons if we let them. Incredible systems can be built with good architecture, design, planning and execution. Technology is important but won’t determine if your system is still providing value in 10 or 20 years.
So, if this is what architecture can do for us, how does an architect go about achieving these goals? The following list gets to the heart of how architects bring value to their organization:
Inquire – Architects are asked to solve specific problems. Getting to the core of the problem and soliciting requirements is the first step in addressing any given set of requirements. Of course, the requirements are often vague, and presented in the limited focus of a specific application domain. So, the inquiry must solicit specific requirements and goals, as well as an understanding of how those requirements fit into the broader enterprise context.
Integrate – Architects act as a bridge between a given project and how that project fits into the broader context. One of the major benefits that an architect brings to the enterprise is in integrating the solution for the particular project with the business domain, information models, enterprise concerns, industry standards, established patterns, and best practices.
Analyze – Next, an architect has to analyze the information that they have collected. The analysis consists of answering three architectural questions: 1) What are the key elements of the problem or solution? 2) What are the relationships between them? and 3) How do they combine together to provide value higher up?
Conceptualize – Once the overall, integrated solution is framed, the architect needs to create a conceptual vision of the solution. This will typically be in the form of a ‘conceptual architecture diagram’, a drawing that shows the major users / channels of the system, the other systems it has to interact with, the major logical functions and data that it must perform or use, and that establishes the scope of the project within those pieces.
 
Abstract – The architect also has to communicate the key details to many audiences. Abstraction can be defined as the suppression of irrelevant detail. So, the architect must establish what details are and are not important for conveying each architectural message to each different stakeholder.
Visualize – They say a picture is worth a thousand words. It is also an excellent way to represent the architectural models and drawings at each level of abstraction. So, another key skill and function of the architect is to create visual renditions of the different abstractions.
.
Formalize – Of course, architecture needs to be more than just pretty pictures. It needs to be specific enough to unambiguously communicate the details to whoever is going to implement the architecture. An architectural ‘specification’ is the usual approach to formalization. But, the specification does not have to be a document. A visualization in the form of a complete and precise formal model, expressed in industry standard notation is often more beneficial.
Communicate – Fundamentally, architects are in the role of communicator. After they establish and formalize a solution, they need to communicate that solution as well as its importance and value to stakeholders throughout the organization.
 
Enable – Even the best designed, formalized and communicated architecture may not be successful. The equation for architecture value is actually pretty straightforward. If using architecture will make someone’s job easier, they’ll use it. If it adds extra steps and work, without adding extra value, it will be ignored.
Assist – Finally, one of the primary enablers is to actively assist projects in using architecture. This is the single most important activity an architect can do to make their architecture real. Virtually all successful architecture programs include some aspect of consulting to projects
The list is not complete, but hopefully will give you some food for thought. Is this what you or architects at your organization do? Are you missing or skipping some important steps? Are you spending time on the right activities that bring value to your organization?