Searching for Artifacts

April 8, 2011 | , ,

Ar·ti·fact: An object produced or shaped by human craft, especially a tool,
weapon,
or ornament of archaeological or historical interest.”
The American Heritage Dictionary

Interesting. In the software engineering field an artifact is:

  • Shaped by human craft;
  • in fact, a very powerful tool;
  • can and will sometimes be used as a weapon;
  • has been known (given a decent plotter) to ornament many a cube; and,
  • two years down the road is certainly of historical interest.

The Treasury Enterprise Architecture Framework (TEAF) provides a more precise definition of the software engineering use of the term – “An abstract representation of some aspect of an existing or to-be-built system, component, or view. Examples of individual artifacts are a graphical model, structured model, tabular data, and structured or unstructured narrative. Individual artifacts may be aggregated.”

To the lay person, an artifact is simply a document.

I was once assigned by a client to provide architecture guidance to a project that was well underway. We seem to frequently have the pleasure of catching up with a project much like a person on a bike catches up with a bullet train – we try our best to catch up, but certainly have to pedal fast. Incidentally, architectural legs do pedal faster with conditioning.

I knew there was a problem when the conversation started like this:

Me: Hello, I am really excited to come on board… insert really smooth introduction to the value of architecture here… so if you send over whatever requirements documents you have, I can ramp up and ensure that the technology solution aligns with your business needs.
Stakeholder: We don’t have a requirements document.
Me: Insert dumbfounded stare here. But you have a signed time and materials contract with the vendor. How are you going to ensure you get what you want?
Stakeholder: We know what we want and I explained it to them. Instantly demoted from “stakeholder” to “person on phone”

True story.

You might be able to get by without requirement and design artifacts if you are designing for yourself and are your own stakeholder or if the number of stakeholders is extremely small and highly engaged in your design process. Even in those situations, your project would benefit from artifacts. In our experience there are very few projects where the problem and the solution cannot be better understood with an appropriate level of artifacts.

We’ll save discussion of “an appropriate level” for another day…

 

Dan Hughes
Dan Hughes is a principal consultant and partner at Systems Flow, Inc., where he leads the technology services practice. He has 20 years of software engineering experience spanning a broad range of technologies and techniques. Startup to enterprise, he has launched, managed, and executed all aspects of both product and enterprise life cycle, delivering complex, enterprise-scale architectures for clients in the public and private sector, in industries ranging from banking and insurance to international development. Dan holds a Bachelor of Science in Computer and Systems Engineering from Rensselaer Polytechnic Institute. For more details, please visit Dan's LinkedIn profile
Dan Hughes

Latest posts by Dan Hughes (see all)



Comments

Comments are closed.