This post is the second in a series on Ubiquitous Language and Domain-Driven Design.

Photo courtesy of Lukjonis

Last week, I wrote about the difference between jargon and communication and how, in the context of a software-intensive system, jargon necessitates either translation between domain experts and developers or the creation of a new, shared language that all parties exercise.

Translation is time-consuming and expensive--an increased communication cost that lengthens software development efforts. Creating a Ubiquitous Language has a cost as well--an up-front investment in creating and exercising the language--but that cost is quickly recouped in the increased velocity of the development team.

The truth is that the communication cost incurred by translation has other ripples throughout our systems. The phrase “Lost in Translation” is not only true in cultural language, but in the jargon-filled domains of our customers and clients. When we allow the need for translation to embed itself in our projects, we invite misunderstanding and, as a result, a far greater cost than just the time it takes to mediate between conflicting terminology.

Beyond the mounting cost of translation, I propose that every misunderstanding between domain experts and developers will ultimately propagate into our software as a bug.

Every Misunderstanding is a Bug in the System

Let’s consider this by way of an example.

Our development team is working on an event management dashboard for a marketing company. Metrics are important to this company, because the success of events is measured in impressions, touches and exposure. As a result, the domain expert would like to ensure that the dashboard includes metrics that give the on-site marketing teams a real-time count of relevant information.

Sounds simple? Consider this:

Domain expert: So we’ll need to provide the marketing teams with the number of opt-ins, the number of players in the game, the number of winners in the game and the total number of times the game has been played.

Technical expert: Ok, so each MARKETING TEAM will need to see those EVENT METRICS on their DASHBOARD.

Domain expert: Yeah, and each of those numbers is a feed for each team.

It’s a common occurrence in a conversation with a domain expert to hear terms that are ambiguous, overloaded in meaning or even brand new to the domain expert. In this example, the domain expert has chosen the term “feed” to represent a number on a marketing dashboard screen. To most development teams, the term feed is quite overloaded in meaning. Could the domain expert possibly mean that each number should be an RSS or Data feed? If so, does the expert expect that these numbers will be published to the dashboard, and should also be consumable via a public service or RSS/ATOM feed? Or does the expert mean something else entirely?

The only way to know for sure is to ask. But the truth is, we often don’t. I’ve been guilty many times in the past of not asking the next series of questions. Many of us have, either because we think we understand “the business” better than we actually do, or because we only have two weeks to get our project out the door when we really needed two months.

So we make an assumption. In this case, we assume that the domain expert wants that RSS feed delivered by a fancy RESTful service when the truth is much simpler:

Technical expert: Feed?

Domain expert:  Yeah, a feed.

Technical expert: Do you mean that each number should available for anyone to see via a public URL?

Domain expert: Oh, no. I just mean that the numbers should be real-time.

Technical expert: Ah, ok. And each number will be a count for only that MARKETING TEAM and EVENT, right?

Domain expert: yes, exactly. And I’d like for those numbers to really be real-time. My MARKETING TEAMS should trust that they are up-to-the-minute and not have to refresh the page.

Technical expert: Ok, that’s important. So you want those numbers to refresh automatically, without initiation by a  MARKETING TEAM MEMBER.

Domain expert: yes.

As it turns out, by “feed,” the domain expert meant a real-time count of a metric for an EVENT and MARKETING TEAM. By assuming anything else, we run the risk of introducing at least two bugs in the system:

1. An over engineered solution – Overproduction, also a serious waste in Lean terminology, can be considered a bug in the sense that the system yields an “unexpected result.” This is not “exceeding expectations,” it’s wasting the customer’s time and money. It’s YAGNI, plain and simple.
2. A missed requirement – By assuming that the customer wanted a RSS feed, we likely missed the fact that what he really wanted was a real-time count of the data, and one that updated on the screen automatically. By not delivering such functionality, we’ve missed a key requirement and as such, introduced another bug into the system.

It’s common in language for us to use a term that means one thing when we really mean something else. Because we are intelligent and adaptive creatures, we can absorb these ambiguities and inaccuracies in speech without our brains boiling inside our skulls. But computers are different. A computer program is nothing more than a representation, in code, of how a computer should provide a solution to a business-driven problem domain. Computer programs will do exactly what we tell them to do, every time, with no variation. When we misunderstand anything relevant to the problem domain, and then codify that misunderstanding in how we instruct a computer to act, we are introducing bugs into the system.

Every Misunderstanding? Really? Every. Single. One?

Perhaps I’m being pithy and hyperbolic. I’m willing to admit that we might be right by accident, and avoid a bug as a result. The first time around, at least. But what happens when that feature is revisited or expanded upon later? Or what about when the domain expert requests some additional functionality that, had the team properly understood the problem space, would have been a simple extension to functionality, but is now a rewrite? My statement might be pithy, but I would argue that most of us find it to be experientially true.

I’ll admit that this is all speculation; even anecdotal. But it’s been my own experience in the past that even if I dodge a bullet the first time, I can be assured that there are more rounds in the chamber.

The Bottom Line: Misunderstanding, Like Translation, Has a Cost

As if the cost of translation weren’t enough, misunderstandings between domain experts and development teams results in the added cost of bugs in the system. A Ubiquitous Language, while no guarantor of success, places the right emphasis on eliminating translation and cementing understanding, both of which will drive down cost over time.

Next time, I’ll talk about accuracy and relevance, and how the importance of each in problem and solution spaces underscores the need for a Ubiquitous Language even further.

Words have meaning. Language is important.

These statements are true, and we tend to pay them their proper lip service in both life and in the realm of software development. Sometimes, we even recognize the importance of language in software, and we seek to canonize our internal vernacular through the creation of lexicons, data dictionaries, service catalogs, SLAs, OLAs or wikis.

More often than not, though, these artifacts serve more as historical proof of our best intentions than as living documents that anchor a software development effort. The canon of our language, at least as represented on paper, falls out of phase with the realities of our software and, as a result, collects dust, only warranting mention when someone on the team recalls how useful such a resource might have been to resolve their current struggles with ambiguous and conflicting knowledge.

We know that language is important in software, or we’d never spend the time early on in our efforts to tame it. But do we know how important it is? Do we believe that success in codifying a language is key to success in the creation of a software-intensive system?

Communication

Let’s consider the difference between Communication and Jargon. Communication is the art of using language to convey meaning consistently and clearly. The goal of communication is shared understanding through unambiguous meaning. Consider the following:

Domain expert: When a check payment is sent in, we need verify that the check is legit and then send it to the bank for processing.

Technical expert: What makes it legit?

Domain expert: Valid routing number. Valid account number scheme. And it has to have a signature.

Technical expert: Ok, so we check to make sure those things exist. Then we send to the bank.

Domain expert: Yeah, though I think they only process once per day. So can we hold onto these and only send them once a day?

Technical expert: Sure. We’ll collect these in a batch and fire them off at a set time each day. When do they process?

In the conversation above, the domain expert is attempting to explain a set of needs in their area of concern, the problem space. The technical expert is attempting to understand those needs--the nouns and verbs that “make up” how the domain expert delivers value to the business and their customers—and frame them into how technology will be brought to bear to better enable the domain expert, or the solution space.

Because shared understanding and clarity is a prerequisite to working software, communication is key to the success of any software-intensive system. Clear communication speeds up the creation of working software.

Jargon

Jargon, on the other hand, slows it down.

Jargon, a style of communication, is the practice of using certain words and phrases in a way that assumes known context, and thus, can serve as a shortcut in communication. When both parties have a shared understanding of the terminology in play, jargon serves as a valuable shortcut for individuals short on time (read: everyone). The propensity of technologists for three-letter acronyms (TLAs) illustrates our tendency towards and the value of jargon. When it works, it works well.

The problem is, when it doesn’t work, it fails miserably. It necessitates translation, clarification and it slows down the whole process of communication. Here’s an example:

Domain Expert: We need to make sure that our support staff can change the rules that we use to create policies for customers.

Architect: ok, so we’ll use a Strategy pattern and make that config-driven…

Developer: we could just use IoC, build strategies for each implementation and let the users swap out implementations whenever they need to change them.

Architect: That’s an option too. We’ll figure it out offline.

Domain Expert: (confused) So will the support staff be able to change those?

Architect: Sure, they’ll change config and it will just work.

Developer: Or swap out an implementation for the container in config.

Expert: What’s IoC?

Architect: well…

When technical experts and domain experts come together to solve a business problem, each brings a certain amount of jargon from their vernacular. Each party is used to spending much of their time with other individuals who understand that jargon. But between domain and technical experts, there is often little overlap between the jargon of the business and the jargon of technology. As a result, when one party leans too heavily on the jargon of their concern, communication stalls.

To keep communication clear, we need a language that assigns meaning to the terminology we use in our contexts.

Ubiquitous Language – The Jargon Killer?

In Domain-Driven Design, Eric Evans advocates for the establishment of a Ubiquitous Language on any complex software project. According to Evans, a Ubiquitous Language is, “A language structured around the domain model and used by all team members to connect all the activities of the team with the software.” (DDD Community emphasis mine)

The purpose of that language is to provide clarity and consistency all the way down to the code. The language is continuously exercised, defined and refined through speech, documentation and, most importantly, code. Accuracy in speech is emphasized, because the words we use when sitting around the requirements table will be the same words that manifest the problem space in code.

So then how do we cope with jargon in our problem and solution spaces? Do we eliminate all jargon and force both parties to come up with new, creative ways to explain themselves and what they know?

Actually, no. I would argue that while some jargon should be jettisoned--especially that jargon that tends to be used as verbal filler (think empty business phraseology like “open the kimono” or “at the end of the day.”)—some should be embraced and formalized into our language.

The fact is that some jargon, technical and business, has the potential to be quite valuable and, once consistently established in the minds of both domain and technology experts, can continue to be a powerful shortcut while remaining clear and consistent.

For example, take Multimedia Messaging Service (MMS) and Short Message Service (SMS) in the context of a project with a mobile-marketing company. Both terms are technical in nature and filled with jargon, yet both domain and technical experts have some level of mainstream understanding of these terms, thanks to the popularity of mobile messaging. Ambiguities exist--many business experts might think, due to carrier branding, that MMS supports picture messages only, as opposed to other forms of multimedia like audio and video—but an overlap in understanding makes these terms perfect candidates for language adoption. Once formal meaning (in the context of the business domain) is brought to these terms, they can be used clearly, and provide the benefit of communicating additional details (acceptable message length, transport technologies, media types supported, etc.) to all parties.

Choosing which pieces of jargon are relevant, which are not, and then formalizing terminology is one of the many aspects of creating and growing a Ubiquitous Language.

The key is finding the valuable jargon, and then turning it into true communication.

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.

I had a great time at IASA Denver last night. My presentation included some great discussion among the group about workflow systems and the various challenges we all face when addressing a “workflow style” problem.IASA Denver is an amazing community and a real example of how a professional group should be run. Many thanks to Paul, Kevin and Tim for starting and leading such an amazing group. If you’re in CO, consider yourself an architect and aren’t an IASA Denver member, you’re missing out.

If you’re interested, I’ve posted the slides from my talk at SlideShare and have embedded them below. You can also get the slide deck and the code from both of my demos at http://github.com/bsatrom/WorkflowSystems

Now to continue a productive week in CO with the Thought Ascent crew!

If you've read this blog for any length of time where I've posted regularly, you'll know that I'm a pretty big wonk for composition, Composite Apps and all things assembled and reused over coding from scratch.

So it should be no surprise that I'm quite a fan of Windows Workflow Foundation (WF), the Chico Marx of the .NET Framework, underappreciated for it's elegance, simplicity and power to fundamentally change the way that applications are built in the future. Wait, that last part doesn't quite apply to a lesser-known Marx brother, but you get the idea.

I've been interested in WF (If you hear me speak about it, notice that I will never, ever call it "Dub-F." Can't do it.) from the beginning, and have spent the last four months swimming in the deep end with WF, building some key pieces of an integration layer for a payment processing system that Thought Ascent has been working on for some time. Over that time, I've discovered that WF really does have all of the potential I suspected it did, and then some.

WF is a platform that will change the way we look at building applications, and I think that WF is a great example of the kinds of technologies that will move us closer and closer to true composition of applications over the next 5-7 years. Of course, being a Workflow platform released in concert with a universal framework for building connected systems (WCF) and the UI framework of the future (WPF) sort of makes Workflow Foundation like the third member of Destiny's Child. Those other technologies were game changers from day one. WF has an uphill battle to fight for recognition and adoption, but I believe it's the game changer of the future.

Not that it's being ignored, I just think it's been undervalued in the past, typically met with comments from developers and architects like "I get how it works, I just don't see what it's for"or "what does this give me that I can't do myself with code?"

But I see that tone changing, with Microsoft putting a better and better case around Workflow though integration with key technologies, along with richer complimentary services and tighter integrations with WCF.

So why am I telling you all this?

As you may or may not know, the Rocky Mountain Tech Trifecta is coming up in Denver on February 21st. This event will bring together several experts in the world of .NET, SQL and Windows, along with a few wannabees like myself who will present on just about anything you could hope to hear about in a developers conference. And there will be some heavy hitters to be sure: Scott Hanselman, Paul Neilsen, Rob Bagby and others. I'm not worthy...

If you hadnt't guessed from the first paragraphs of this post, I'll be speaking on Windows Workflow Foundation. Here's the abstract for the talk:

The Future of Work and Workflow

Since .NET 3.0, Windows Workflow Foundation (WF) has lived in the shadow of its flashy framework companions WCF and WPF. Yet from the start WF has been, at its core, about new ways of creating durable applications and composable units of work, both of which have the potential to change the way that developers assemble solutions. In this talk, Brandon will cover some of the highlights and recent enhancements to WF (Creating workflow services with WCF and WF, Workflow Persistence and Tracking), tips and tricks for advanced workflow scenarios (using MSMQ with workflow services, custom activities, etc.), and a preview of some upcoming Workflow features in the 4.0 Framework.

If you're close to Denver and haven't signed up yet, you can sign up at www.rmtechtrifecta.com. And if you're planning on coming, drop me a line. It should be a fun day.

And if you're not planning on coming, look for slides and code here over the next few weeks.

Okay quick question, assuming I have any readers left after my far-too-long hiatus.

Assume that the middle box--labeled "Translation"--is EA.

With no explanation from me, what does this graphic mean to you?

What do you think it says that you would agree with?

What does it say that you would dispute?

Interested in hearing your thoughts...

I'm sitting in a session at the Gartner EA Summit entitled "Security Architecture Best Practices." I'll be the first to admit that I don't pay enough attention to the Security side of Enterprise Architecture, which is why I am in this session and plan on attending another complementary session tomorrow. I am surprised to see that, though there are 600 people at this portion of the Summit, there are only about 50 people in this room. So is EA really that far behind the curve in getting on board with Security? What are we all doing beyond adding a vertical "Security" bar to our models? Not much, in my case, but I am feeling that that ought to change, especially in light of some things I am starting to work on which I will blog more about in the coming weeks.

I know that James McGovern cares about security. In fact, he has stated before that he sees it as a form of competitive advantage, which, if true, explains why there are only 50 people in this room. I would expect that to grow year by year.

As for the session itself, so far so good. One salient point that I've heard Gartner preach before, but am now seeing tied to the Security space is that the "Consumerization of IT" should lead us to drive our Security Architecture and Design to enable choice and distributable trust. Personally, I feel that lock down security, the knee-jerk of most Enterprises, is an over-engineering step that will leave us inflexible and closed off from a younger generation of employees and consumers. Thus, I'm glad to see that backed up with some analysis from Gartner.

I'm glad to see Gartner offering sessions such as this in to an EA audience. My advice to them is to continue to offer sessions like this, even if the attendance from this year's summit doesn't suggest that there is an interest. Those numbers will grow.

...and I'll charge you an arm and a leg to make it better. Looks like IBM is starting up a dysfunctional SOA practice. Not surprising really. Consider this quote: "Some organizations may not be happy with their service oriented architectures (SOAs). They may have "unhealthy" SOAs as a consequence of partnering with inexperienced system integrators. They may have proprietary SOA technology in the mix, and it may be difficult to scale operations."

They will probably make a killing since no one agrees on what SOA really means and all IBM has to do is figure out what you think it is, then convince a few key executives that that's the wrong idea, thus rendering them instantly unhappy. It was bad enough when selling the buzzword ruled the day, but selling the band-aid will be worse, I fear. This, my friends, is why we never should have let our executives hear "SOA" in the first place. 

Here's a question: what happens if an organization worked with IBM as their Systems integrator in the first place and is now unhappy with what they got? Would IBM ride in to rescue that organization too? <unrealistic>Maybe for the sake of good-will and a case-study, they'd do it for free.</unrealistic> I wonder how IBM would sell that engagement? Probably by blaming your internal management.

I can't help but think that this is a case of selling me poison, then following that up by telling me I have a deadly poison in my system and that you just so happen to have the antidote. Not that I am calling SOA poison in any way. Conceptually, it's just the opposite.

Maybe I'm overreacting or being too negative here. Any one care to chime in with excitement about this announcement?

Last week, Jean-Jacques Dubray published an article on InfoQ regarding Microsoft's recent announcement of Oslo, a strategy designed to "...take composite applications to the mainstream." Rather than revolving around a single product, Oslo sets strategic direction for Visual Studio, BizTalk, the .Net Framework, Microsoft System Center and a new product called BizTalk Services. On a side note: Arnon Rotem-Gal-Oz hopes that this final project's association with BizTalk is more about branding than actual product similarity, a sentiment I share.

After posting this article, Jean-Jacques sent me an email and asked me to share some of my thoughts on Olso for a follow-up article to be published at InfoQ. I sent my thoughts along on Friday, but thought that I would post them here as well.

When we developed a long-term strategy for Composite Applications at my organization, it was obvious that while Microsoft technologies would have a major role to play in many areas of our future-state architecture, there were several vital pieces missing in the Microsoft stack that we would likely need to find elsewhere. I've always felt that we weren't alone in that sentiment, and the Oslo announcement suggests that Microsoft is also well aware of the gaps in their current offerings. While products like Dynamics CRM and MOSS 2007 offer composition scenarios which I regularly point to as examples of end-user and/ or business analyst composition, Microsoft has long been missing the technologies to unify these experiences under a common framework. Though missing in the products themselves, the Composite Applications vision is one that I have seen preached by Microsoft Architects and blogger's like Mike Walker and others who seem to have a good grasp on the long-term potential of composite applications. The good news about the Oslo announcement is that those individuals are no  longer in the minority. With Oslo, I believe Microsoft has unveiled merely the beginning of a unification strategy that enables composite applications. I believe that this bodes well for clients and non-clients of Microsoft alike.

That being said, There are two reasons why I'm a bit skeptical about the Oslo announcement: For starters, I believe that Microsoft's stated vision for Composite Applications is too narrow. While the Software + Services and SOA visions are needed, I believe that the end goal of any Composite Applications strategy should be to gradually enable composition up the stack toward the end-user. This is done first by providing a SOA which enables true service and process composition, then by extending those principles to developers of customer applications, business analysts and, ultimately, end users. Oslo speaks well to the former, but the latter is auspiciously missing. I actually don't believe that such a goal is absent in the halls of Microsoft, but I do believe that it hasn't permeated across the organization and thus, isn't given a place in the conversation yet.

The second reason I am hesitant to praise Microsoft for the Oslo vision is because their announcement is related to technologies which are anywhere from 1 year to 3 years or more away from release. Most of the tool updates are two releases away. Microsoft is correct when they say in their press releases that 21st century business is moving faster than IT can deliver, but that statement is true today. Organizations need solutions today, not announcements of solutions coming tomorrow. My organization, for example, cannot wait for a repository to manage models, metadata and services (one of the gaps we knew about in our strategy) when our ability to manage all three is already beyond our control. I honestly believe that Microsoft's vision for Oslo is a good one, but they are just now announcing plans to provide functionality that most organizations already know they need, which puts them at a disadvantage with those organizations. I can see a day in my company where many of the pieces in the Oslo stack make their way into our architecture, but today we need to keep moving. Of course, the good news is that when SOA and composite applications are done right, vendor lock-in is reduced and organizations can focus on delivering for the business today instead of waiting for the remaining puzzle pieces to fall in place tomorrow.