Last night, I got word that the article on Domain-Driven Design (DDD) and Emergent Architecture that Paul Rayner and I wrote for The Architecture Journal has been published.

The issue is titled “Architecture Modeling and Processes,” and I’m looking forward to digging into the other articles this weekend. In particular, “UML or DSL: Which Bear Is Best?” fascinates me, both for it’s subject and reference to The Office. I’ll be grabbing the PDF of the issue and loading it up on the Kindle straightaway.

Our article, titled “Keeping Architectures Relevant: Using Domain-Driven Design and Emergent Architecture to
Manage Complexity and Enable Change,” looks to have been chosen as the featured article in the issue, which is exciting and an honor. Click here for an online version (also posted below), here to read the forward with a description of each article and the issue’s theme, and here for a PDF version with all the fancy post-production.

Paul and I would love to hear your thoughts, so feel free to comment here or over at his blog, if you are so inclined. We’d also appreciate it if you’d pass the article along to others in your network whom you think might be interested.

Enjoy, and have a great weekend!

Links:

The Architecture Journal, Issue 23

PDF Version of Issue 23

Note: Cross-posed from Paul Rayner’s Blog.

Last week, I had the opportunity to co-present with IASA Denver chapter president Paul Rayner, at the IASA Austin ITARC Conference. Our presentation was titled “Keeping Architectures Relevant: Using Domain-Driven Design and Emergent Architecture” and is meant to be a helpful introduction to key ideas around DDD, Agile and Architecture, with an emphasis on how an architect can use principles and practices from each of these to keep themselves and their work relevant.

Our presentation was meant to be a brief overview and introduction to the ideas we’ll be covering in our upcoming article (by a similar name) in the Architecture Journal. See my last post for more information about that article. Watch for a link here in mid-March when the article is released.

As Paul states in his post, we really enjoyed presenting and got some great questions during and feedback after the session. We’re planning to give this presentation again soon, so if you were there and you have any additional feedback to offer, we’d love to hear it. We’ll be cross-posting additional content related to the paper and this presentation over the coming weeks, so keep an eye peeled here and Paul’s blog.

Paul Rayner and I recently submitted (and had accepted) a proposal for an article in an upcoming issue of The Architecture Journal. The issue, #23, will center around Architecture Modeling and the tools, tactics and strategies an architect can leverage in modeling his or her architectures.

We’re knee-deep in drafting the paper right now, and it won’t come out until mid-March, but I did want to share the abstract we submitted so you can see what we’re scheming. We’d love to hear and thoughts, ideas or suggestions you might have. 

“Keeping Architectures Relevant: Using Domain-Driven Design and Emergent Architecture to Manage Complexity and Enable Change”

Abstract

Too many systems seem to become legacy upon release, while some never even have a chance to move into production before they are undermined by the calcification of unmet expectations and mismatched domain needs. Regardless of the design effort early in the lifecycle, neglecting the domain model and producing inflexible design results in the increasing irrelevance of the initial architecture of a system. The accidental complexity of that system rises and communication between developers and customers deteriorates. Changes and new features become more difficult to accommodate as the richness and value of the system's essential complexity is eroded. Sustainable and successful software development is all about managing complexity and enabling change, and successful architects create designs that clearly address both.

Architects, domain experts and developers collaborate to mitigate complexity through strategic modeling and design. This requires a focus on the core domain and the continuous application of germane design patterns. Ongoing effort should be expended on defining and refining the domain model through the establishment and exercise of a language that everyone shares. The development of this ubiquitous language, along with the use of domain-driven design techniques, enables business problems and their solutions to be expressed through rich domain models that are both meaningful to business experts and executable by the development team.

Keeping our architectures relevant also means enabling change. As architecture is allowed to emerge, evolve, and mature, it becomes a true reflection of the deep understanding of both domain experts and developers. Architects who expect their initial design to evolve, and who design with evolution in mind, create architectures that deliver a strong competitive advantage to the business.

Reader Takeaways

1) The establishment of a ubiquitous language, which removes the built-in translation layer between domain experts and the development team, is key to relevant modeling.

2) Domain-driven design enables the articulation of a distilled architecture through models that mitigates complexity while remaining relevant to the business and clear to the development team.

3) Architects must collaboratively drive architectures which emerge, evolve and mature in order to deliver systems that improve in their ability to respond to the changing needs of the business.

Last week, Todd Biske linked to my post, "Is Enterprise Architecture Declarative or Imperative?" and added some of his thoughts in a post entitled "Transparency in Architecture." In addition, Adnan Masood left a comment in the original post which made a similar point. Their point: Enterprise Architecture is declarative, but not always and it's not that simple. Adnan agreed that EA is declarative at its best, but mentioned that the "sync up" process I referred to between EA and Solution Architects will have some imperative qualities. Todd also agreed that EA is declarative, but said "... I wouldn't go so far as to say that the path to execution falls to solution architects." Instead, Todd said that EA should define both future state and some very coarse executable actions for achieving that future state. A great point, and I totally agree. The idea of "increasing constraints" as Todd puts it, is a good way to describe the healthy tension at the EA/ SA handoff. Our VP of IT calls this "Freedom within a Framework," a term which I believe captures the essence of how EA can be declarative. We're not going to sit in your code reviews, but we do care how you are using Enterprise Information and upon which platforms you are delivering solutions to our customers. I heard Gartner Analyst Anne Lapkin once state that EA constrains IT for the good of the business. So, If EA is both the Keepers of the Flame and the stewards of strategy, we have to care. And you, whomever you may be, should demand that we care so you can be free to care about what you need to, be it well-run projects, well-crafted and innovative solutions, or a well-thought-of and profitable IT organization.

The second part of Todd's post discussed the topic of governance and how projects constrained by EA should be transparent. While I like this idea far better than being pulled into a million meetings (or, more importantly, making teams feel that they can't be trusted and must be looked after), that kind of transparency is a tall order in most situations I've been in, which Todd also states. But I like this idea and can see its parallels to the concept of Information Radiators in agile software development. In the same way that I can wander into a war room or bullpen and find out basic and essential information about a project (backlog, burndown, etc), these "Architecture Radiators" could provide me with the information I would need to asses the state of the architecture of the project and track its evolution over time.

But that's just theory... what would such a thing look like? It would have to be both simple to maintain and useful. I'll have to think on this some more. In the meantime, does anyone have any ideas or examples from projects where these types of Information Radiators existed?