Agile Data Design – February 2012

With the New Year comes a new job: I am leaving behind (mostly) my former role as a database developer and DBA, and moving on to a new role as an Enterprise Data Architect at my company. I am very excited about this new role, as it offers me an opportunity to apply the ideas about Agile data management from my book, Building The Agile Database (Technics Publications: to the broader field of data architecture and data governance. Therefore, this is the first article of my new quarterly column “Agile Data Design.” (My “Conquering the Logical/Physical Divide” columns can still be found on TDAN — just click here).

As I said in my last article,1 the Agile approach does not mean that you can’t do up-front architecture and design, nor does Agile represent a choice between doing architecture and design and not doing architecture and design. You need to do architecture and design; it’s just a question of how much of each is done when, how often, and by whom. An Agile approach to architecture does not mean that all requirements are defined up-front and a defined process exists for every possible contingency. It means that at each phase of a project there is “just enough” definition and process to guide the project through the rocky shoals of uncertainty, and get it safely to the next step, and the next, and the next, until the end goal or vision has been achieved.

An Agile approach to architecture and design will also satisfy the following criteria:

  • It will be stakeholder-based, ensuring that everyone with an interest in the outcome will have input into the solution.
  • It will be business-focused, concentrating on the goals and objectives of the business (and not on architectural processes and artifacts per se).
  • The outcome of any solution will be a cross-domain set of business processes and architectural artifacts (policies, standards, bricks, patterns) that can be packaged and reused for every delivery of that solution. In other words, once a solution to a business problem has been found (or the delivery of a needed piece of business functionality has been achieved), it should no longer be necessary to “reinvent the wheel” when the next application of this solution is needed. This is one of the most important uses of architecture – it enables you to develop a solution once, and reuse it multiple times!
  • It shouldn’t be overly prescriptive; that is, it shouldn’t attempt to answer every question and provide for every contingency in advance. In particular, an Agile approach to architecture should acknowledge those situations for which defined solutions will not exist, and can’t be created in a timely fashion. These include the first application of a new technology or business process within an organization, a defensive response to a business exigency requiring a quick, short-term, ad hoc solution, and an offensive response to a “now or never” opportunity for competitive advantage. In these cases, the solution may (or may not) be guided by existing architectural processes and artifacts, but will not become part of the defined architecture until and unless it is packaged for reuse within the company. This is analogous to the difference between enterprise databases (which can be reused for multiple applications and uses of data) and one-off departmental or application-specific databases.
In other words, an Agile approach to architecture ensures that processes and artifacts guide the development of business solutions to: a) ensure that they align with business goals and objectives, b) deliver the maximum amount of benefit to the business in the shortest amount of time, and c) can be reused to deliver repeated value.

If all of this sounds familiar, it’s because I’ve developed these ideas over the years as part of my approach to Agile data management, and they form the core of my book.

Fortunately, the approach to enterprise architecture used by my company (which is based on the Sogeti methodology) is an excellent fit for these principles. The Sogeti methodology (also called “Dynamic Architecture” or DYA) provides for a “strategic dialogue” among business stakeholders, a determination of the extent to which governance should be applied in the development of a solution, and a set of “architectural services” that can be applied to guide that development.2  

 I will be very busy in the months ahead, as the Domain Architect for the data and BI domains (these are actually sub-domains of the information architecture domain). I will be reviewing and updating (and in some cases, creating) the artifacts that guide business and technology decisions in these domain areas; I’ll be creating 1 to 5-year architecture roadmaps for data and BI, describing the projects and technology we will use to achieve our company’s business goals in these areas; and I’ll be figuring out how to communicate our data and BI standards and processes to our company’s new IT partners in India. Lots of work, and a huge learning curve, lies ahead! I’ll keep you posted, in this column, on my journey of discovery.

NOTE: I’d like to make this a dialogue, so please feel free to email questions, comments and concerns to me. Thanks for reading!


  1. Burns, Larry. “A Building or a Garden.”  TDAN, November 1, 2011 (
  2. For more information about Dynamic Architecture and the Sogeti methodology, see Be sure to click the “English” link at the upper-left of the home page!

Share this post

Larry Burns

Larry Burns

Larry Burns has worked in IT for more than 40 years as a data architect, database developer, DBA, data modeler, application developer, consultant, and teacher. He holds a B.S. in Mathematics from the University of Washington, and a Master’s degree in Software Engineering from Seattle University. He most recently worked for a global Fortune 200 company as a Data and BI Architect and Data Engineer (i.e., data modeler). He contributed material on Database Development and Database Operations Management to the first edition of DAMA International’s Data Management Body of Knowledge (DAMA-DMBOK) and is a former instructor and advisor in the certificate program for Data Resource Management at the University of Washington in Seattle. He has written numerous articles for and and is the author of Building the Agile Database (Technics Publications LLC, 2011), Growing Business Intelligence (Technics Publications LLC, 2016), and Data Model Storytelling (Technics Publications LLC, 2021).

scroll to top
We use technologies such as cookies to understand how you use our site and to provide a better user experience. This includes personalizing content, using analytics and improving site operations. We may share your information about your use of our site with third parties in accordance with our Privacy Policy. You can change your cookie settings as described here at any time, but parts of our site may not function correctly without them. By continuing to use our site, you agree that we can save cookies on your device, unless you have disabled cookies.
I Accept