As business or technology architects we all create tons of artifacts — documents, diagrams, whiteboard scribbles, and presentations. The question I and a other architects were musing about this week was “what is the value of all this stuff we create?” How much of this stuff is shelfware and how much is truly useful? Some of us think that the federal acquisition process demands it but the content is not accurate and might even be irrelevant.
One of the discussion members said that, from a programmatic perspective, architecture artifacts can, if done appropriately: (1) be of very high value in communicating with oversight officials (and that brings funding), and (2) bridge programs for interoperability.
I tend to think that most of the artifacts we generate are for helping ourselves understand what we’re doing and convey our principles, concepts, designs, and plans for others to better understand what we think we know. Ultimately, even if it’s shelfware it seems that all architecture artifacts have some value — even if it’s just historical value. The key is that we don’t create artifacts for the sake of those artifacts but for the sake of increasing communications.
What are your thoughts on architecture artifacts? What rules do you use to create “just the right amount?”
#1 by starai at August 29th, 2008
I agree that some artifacts are very valuable…..at least for a while. We should look at our inventory and assess current value. But I’d like to address how artificats are created with little value. This often happens when the motivation is checking the box. Also concider the oversight the assesses value. Does it exist?
#2 by Chris.Gunderson at August 29th, 2008
Architectural artifacts may or may not be useful to a particular engineer building a particular information system. However, when it comes to either draconian compliance enforcement, or more enlightened validation of value added, prognostic artifacts are irrelevant. What matters is how the delivered structure is actually constructed and how it performs. So… we need DIAGNOSTIC architectural artifacts that are created as a by product of our test and evaluation and validation and verification processes. Given the application abstractions that are trivially available in modern network architectures, generating these diagnostic artifacts should be pretty easy. However, at least in the DoD, the architectural artifacts required to demonstrate compliance and value are not coupled to actual run time activity.
#3 by kpburk3 at August 29th, 2008
At the practitioner level (actually building a system), my experience has been that architecture products add little value. If fact they can be quite a tax in a DoD program environment if one is changed with maintaining them. However, from a programmatic perspective, architecture artifacts can, if done appropriately be of very high value in communicating with oversight officials (and that brings funding). They can also bridge interrelated programs toward interoperability. For example when I was in Army Medical IT business in 1999-2001, the Medical and Logistics DODAF architecture products provided substantial means of aligning both programs and technical architecture. These views provided a lexicon for several communities of practice to communicate, collaborate and develop plans.
Mark Maier’s work “The Art of Systems Architecting “ is the best I have seen, I actually ref to it every six months or so
One of the key concepts I remember from hearing Dr. Maier speak was that Architecture is not about “views” or “perspectives” as many EA proponents advocate. *** It is an identification and measurement of Quality Attributes. *** What are the Quality Attributes of the system or enterprise under consideration, and how can we measure them? Architecture efforts must be able to address these questions.
http://www.amazon.com/Art-Systems-Architecting-Second/dp/0849304407
#4 by cliffbdf at February 24th, 2009
kpburk3’s discussion of quality attributes is right on. As I point out in my book Value-Driven IT, most of the difficult issues in architecture have to do with non-functional requirements. Yet, so much effort goes into functional architecture. This is why one hears so often about data synchronization problems between systems, scalability problems, and so on.