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.
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!
References:
- Burns, Larry. “A Building or a Garden.” TDAN, November 1, 2011 (http://www.tdan.com/view-featured-columns/15636).
- For more information about Dynamic Architecture and the Sogeti methodology, see www.dya.info. Be sure to click the “English” link at the upper-left of the home page!
