Like on any enterprise initiative, there are many people involved in building the eneterprise architecture: leaders, subject matter experts (SME), users, stakeholders, and the architects themselves. And for each of these categories, their may be numerous individuals or groups with valuable ideas and content and design input.
Even for the architects themselves, there may be many involved in building an EA information product for the enterprise: for example, there’s the chief enteprise architect with the overall strategy for the architecture; there may be the architect that’s the “architecture subject matter expert” whose most familiar with the particular content area like databases, IT security, SOA, etc., another may have the contact (or “relationship”) with the relevant leadership and business/technical SMEs, while another may be the team’s design guru able to visualize or model the content into an easy to read and understand end-product, and various others (like the EA configuration manager, EA communications manager, and so on). In general, the larger and more complex the enterprise, the more business and technical people and specialists involved in building the architecture.
So it’s not hard to see, with the various SMEs and specialists involved in building often many information products simultaneously, how information products can ‘get stuck’ along the way in the development process.
From a User-centric EA perspective, it’s the role of the chief enterprise architect (
"keep the wheels on the road" and "keep ‘em turning." In other words, the
However, when the process does get stuck along the way, one way that the
DADS are product design and development sessions, where I "sequester" the relevant SMEs in a conference room. Mandatory is a large white board. And then we close the door (and don’t let anyone out, except for bio breaks— sort of kidding) until we have a draft information product. When everyone is prepared with their materials, it usually only takes an hour or two. But focusing everyone on the objective and bridging the divides, helps get them over the proverbial ‘finish line’.
DADS are a very successful tool when done right. Recently, for example, I’ve helped an organization develop almost 50 "useful and usable" EA information products in less than 9 months!
The DADS (like JAD sessions for application development) can rapidly move an organization along the EA maturity cycle and from product development and maintenance to levaraging use of the information for IT planning, governance, and decision-making in the enterprise.