Code Confessions

For decades enterprises have understood the database as the true technical authority. No matter what insanity we application developers create, the relational database, by enforcing constraints and referential consistency, by disallowing nulls and protecting unique values with its transactions and ACID principles – it keeps the chaos at bay and gives us Truth.

But nothing is free. Requiring all domain truth to be expressible with a single model, the relational entity store, is like painting the world with only primary colors. The subtleness of the domain is lost. Meaningful questions are obscured by the checklist of entity relational questions. Should the customer’s name be 50 characters or 100 characters? Should it be non nullable? In what aggregate does it belong? These questions hide more important question – What is the purpose of this data to the enterprise? In what context is it valuable?

Entities come with baggage. They stop us from thinking YAGNI at an architectural level. If we don’t need the data, we shouldn’t persist it. If we don’t need an event, we shouldn’t publish it. If a tree falls in the forest, unless it serves a purpose in the forest service business capability, it will not publish a sound event.

The hardest part of SOA is getting past our preconceived notions of what business is all about. We have them at many levels. We have baked them into relational databases and we have "anemic domain" models in our heads from years of repetitive system design. To get SOA right, we first have to get over ourselves.

This is my interpretation of what I learned in Udi’s SOA course. I highly recommend everyone take his course or at a minimum rent his videos.

Last time we discussed what service oriented architecture is. We discovered that services should align with and enforce enterprise semantics and rules instead of tangentially relate to them like applications tend to do.

This brings me to Udi’s definition of a service which works well with my preferred definition of SOA:

A service is the technical authority over a specific business capability. Any piece of data or rule must be owned by only one service. – Udi Dahan

"Technical authority" is intentionally strong. To be an authority means to have power of determination.

An authoritative service owns completely its data, its schema, and its concept of consistency. No outside force may tell a service what is true inside its boundary For example, enforcing referential consistency in a database across services is disallowed; This impedes on the technical authority of the service over its data.

A service also owns its business rules. To own a rule, a service must be able to change its interpretation of a rule without "issuing a memo". Other services shouldn’t be affected by this change. This is stronger than loosely coupled – this is autonomous.

To be autonomous as discussed in this blog post requires services to communicate asynchronously. If services make synchronous calls we have created strong temporal coupling between our services.

A more surprising takeaway of being a technical authority is that services must own their presentation elements. This means our applications will decouple orthogonally instead of horizontally as services will bundles data, schema, business rules and presentation elements together.

Providing presentation elements isn’t the same as a full blown stylized UI; A separate branding service is responsible for that. Instead, services emit a small amount of HTML or JSON or own an MVC controller. This is controversial as horizontally decoupling has been beaten into our skull for so many years. But it makes sense if services have been constructed at the right level of granularity.

With almost territorial delineation between services, how do we build applications? Udi notes in this blog post that applications are simply mashups of autonomous services. Applications are loosely communicating context aware services. The job of applications is to provide context to services.

Udi didn’t cover why he chose the specific language of business capability instead of the more familiar business process. Business capabilities describe what a business does – the functions that a business performs (use cases at a high level). Processes, on the other hand, define how a business operates and are anchored in today’s thinking about the business. For example, a business capability might be "Generate Bill". The specifics of how a bill is generated – whether we create a PDF or generate an email, is the process.

Sounds great, but if we don’t create code that actually does Print PDFs or send emails, nothing gets implemented. So why capabilities? Because they maps well to services. A capability is at the right level of granularity to be represented with a service. Capabilities are black boxes that encapsulate the processes they perform. Services are the same, sharing minimally and to observers (if constructed correctly) autonomous black boxes of functionality. Capabilities are stable over time. For our investment in services to be valuable, they too must be stable over time. The implementation can change as the environment and organizations changes, but services boundaries need not be redefined, just as the core business capabilities rarely need be redefined.

Now that we have a good idea of what we want out of our services, we can start talking about the moving parts that make all of this SOA machinery work.

This is my interpretation of what I learned from Udi’s 5 day intensive SOA course.

To learn something complex and paradigm shifting like service oriented architecture (SOA) can be tough. It’s doubly difficult when there is little agreement on what the definition of the thing being learned is.

If you look into its earliest history, SOA is usually defined in terms of specific technical stacks such as SOAP. The W3 penned a more general definition when it defined SOA. The W3 discusses the desirable characteristics of SOA such as exposing metadata, network friendly, and platform neutrality.

My problem with these (and many) definitions of SOA is they lean too technical. If SOA is just another technical stack, it’s not an architecture, it’s an implementation.

The definition of SOA I found which I like the most is from this article by Boris Lublinsky. it states that:

SOA can be defined as an architectural style promoting the concept of business-aligned enterprise service as the fundamental unit of designing, building, and composing enterprise business solutions. Multiple patterns, defining design, implementations, and deployment of the SOA solutions, complete this style – Boris Lublinsky

What I like best about this definition is the emphasis on services as a unit of business alignment.

According to Boris, because of the way IT needs are addressed, the enterprise becomes a mesh of siloed applications, each created with only partial business alignment. Enterprise business processes becomes shaded by application specific purposes. According to the article applications "manifest themselves as islands of data and islands of automation."

Islands of data develop when enterprise concepts are defined narrowly to meet specific application needs. These islands of data cause semantic dissonance as each application models a tiny, discolored slice of the enterprise concept. Such islands results in difficult to reconcile data duplication between applications. For example, an insurance claims application may contain demographics in a different format then a CRM application. They may be similar but not the same.

Islands of automation are the applications themselves. These force enterprise users to "application hop" in order to complete meaningful work. Business processes become disjointed, often requiring users to copy and paste between applications or invoke multiple executables or web sites to perform work. This context switching costs the enterprise in terms of lost time, concentration, and duplication of efforts.

SOA then, as an architectural style, should strive to end semantic dissonance in the enterprise and bring about business alignment. SOA should tear apart application islands in order to reconstruct the enterprise as a series of autonomous services, each with clear ownership and responsibility for its semantic concepts and business rules.

This means if we want to do more than pay lip service to SOA we’re going to have to cause some enterprise pain. According to Conway’s law the enterprise will produce designs which are copies of the communication structures of these organizations.

This means if we have four teams bent on doing SOA but projects are divided up around existing application silos, we’ll just get four additional silo applications. According to Conway, if we divide IT by technical lines (Development, Management, Support, Help Desk) we will find each group acting autonomously and aligning along technical boundaries rather than business aligned service boundaries.

If we want to do SOA with a capital S and reap all of its rewards, we must accept it will involve changes to IT. How projects are conceived and budgeted, how teams are formed, even the very structure of IT governance will need to be examined.

Next time we will discuss Udi’s definition of a service and how it is critical to a successful SOA.

This is my interpretation of what I learned from Udi’s 5 day intensive SOA course.

Most of the other fallacies are well documented elsewhere and I don’t want to steal Udi’s thunder by covering them in depth here. As I urged, take his course!

The last three fallacies were penned by Ted Neward of both Java and .NET fame. The first two can be found in his magnum opus Effective Enterprise Java, and the last in a blog post lamenting that he wished it had made the book. The very last one is of particular interest because it is the most controversial: Business Logic Can and Should be Centralized.

When Ted discussed the 11th fallacy, he’s talking about the fact that business logic is going to necessarily be distributed in a distributed system – that we will need to enforce the same rules on clients, on servers, in databases. As Ted states, this is a hard one to swallow, because we believe in DRY (Don’t repeat yourself). We want to write per the Once and Only Once Rule. We feel like bad programmers when we repeat ourselves.

What do we do when in one ear the Pragmatic Programmers are whispering “don’t repeat yourself!” and in the other ear “Coupling is bad!” How do we not repeat ourselves and keep a decoupled architecture? If we write it only once, we will be coupled to it everywhere it is used. But decentralize our rules, we have repeated ourselves. How can we resolve such things?

Udi has a quote I feel is brilliant.

When two principles are pushing in opposite directions, some underlying assumption is wrong. Often the word the is the culprit – Udi Dahan

What a beautiful insight!

If loose coupling and DRY are pushing in opposite directions what assumption is wrong?

At this point we have to ask – why are we are striving for DRY in business rules anyway (aside from the fact some old guys with beards told us it was the right thing to do)? Udi points out it’s not making changes in repeated code that is hard, it’s finding all the places where changes need to be made!

So what assumption is wrong? Where is the word “the” causing us pain? Udi offers that we have one “the view” of an architecture. Instead of trying to centralize business logic with DRY – why not have multiple views of your architecture? What if we tagged each requirement so that with a simple GREP query we could easily find everything related to a business rule and make a code change? Giving credit where due, Udi attributes this idea to Philip Kruchten’s paper Architectural Blueprints—The “4+1” View Model of Software.

Does this smack at the extreme programming view that “the code" is the only model? Possibly. I defer the reader to Eric Evan’s work in Domain Driven Design where he says “Documents should work for a living.” I can’t think of a better way for user stories / requirements to stay alive and relevant than to have them cross reference directly with the actual code that implements them in a “requirement view” of our architecture.

This is my interpretation of what I learned in Udi’s SOA course

In my last post I lamented the pain felt applying object orientation to distributed architectures but I didn’t talk about why. To understand this, it helps to look back to Peter Deutch’s fallacies of distributed computing (If you want to learn more about these fallacies go here)

One of the first systems I developed was a wireless restaurant point of sale system. A key feature was waitstaff could send customer orders wirelessly with handheld devices to a backend server. This sounds like a simple enough system to build. And it is at development time with a device emulator running on the same machine as the application server. With this setup, it’s easy to fall into a trap. We code oblivious to Peter’s first fallacy, that the network is reliable, because we abstracted the network away somewhere. All is fine until deployment, because that is when Microwave ovens disrupt 802.11B devices, staff trip over cords and send PCs or switches offline and phone systems go in that compete with your wireless signal. That is when impenetrable cinderblock walls and the electric surges of heavy machinery wreak havoc on your network.

RPC (remote procedure call) technologies make the situation worse. Network is down? You get a timeout error. Want to retry? Implement it yourself.

I did that with the restaurant system. I devised retry logic so that waitstaff could move back into the wireless range and try sending the order again if it failed the first time. But this introduces another problem with RPC over unreliable networks. With RPC there are two distinct outcomes for a timeout. First, the RPC call may have never reached the server. In the case of our restaurant system, we would have hungry, angry customers unless the system retries to send the order. But what about the second outcome? What if the order did reach the server and the timeout occurred on the way back? If this is the case, and the waitstaff retries, the order is received twice. This means we requested double food (unless our services are idempotent)!

So is RPC over networks always bad? Actually many successful, distributed systems have been built on RPC. To say “the network is unreliable” is too binary. Reliability is a range with my scary restaurant network on one side and mission critical no single point of failure networks on the other. The abstractions afforded by RPC are acceptable for many non mission critical systems. Yet if there is another pattern, another abstraction that’s not much more complicated and does bring more reliability, shouldn’t we look to it?

When it has to be as reliable as possible, there are two choices. First, you can implement socket level communication. This means doing the connects, retries, and reconnects yourself. I’ve done that when implementing clients for mainframe messaging. It’s not terribly fun but it is effective. Second, you can use a reliable messaging pattern to smooth out the inherently unreliable network. In a future post I’ll talk about what patterns are applicable.

In the end, there is no 100% reliability once you introduce a network. This is clearly illustrated by the two generals problem. But that doesn’t mean we should throw up our hands. It means we need to do what we’ve always done as IT professionals – make good tradeoffs and think deeply about when and where we need specific nonfunctional requirements such as levels of reliabiity.

This is my interpretation of what I learned from Udi’s 5 day intensive SOA course.

One of the pronounced themes of the course is that we have misapplied familiar software patterns in an attempt to abstract away the complexities of distributed computing.

For a long time it was reasonably hard to do application level computing over a network. Even simple client /server operations required programming at the socket level. Yet application developers being who we are, we wanted abstractions. We had business needs to address. We didn’t want to get down into the weeds just to get computers talking to each other.

As object oriented programming was such a singular, dominant paradigm in the 80′s and early 90′s, object oriented solutions were developed to the network problem. So entered CORBA and DCOM. These technologies should have showed us once and for all how badly object orientation maps to distributed computing. But instead of realizing that the pattern was mismatched to the needs of distributed computing, the implementation and interpretation were blamed.

The rapid growth of the Internet exacerbated the problem as software vendors scrambled to create tools that met existing customer mental models while answering the question of how we were going to get all of this networking stuff to work. It was in this period that .NET became the premier tool for writing business code on the Windows platform.  With it came the promise of “web services".

If you are old enough to remember .NET’s launch, it was about web services. The plan was we would give up the component based VB6 application development model and move our apps to the web. Component vendors would become web service vendors, billing us per request. For example, instead of adding a spell checking component to our applications, we would send our documents into the ether for a remote spell check by a vendor, paying a mere penny or so for the privilege.

Inspired, us developers started building applications using web services and our trusty three tiers. It became a "best practice" to not let a web application UI (sitting on a server) talk to a database (often sitting on the same server) without going through a web service business layer (you got it.. on the same server). Developers were told that a tiered architecture was a decoupled architecture and that a decoupled architectures would be more manageable, more agile, and let us scale as future needs dictated.

So it wasn’t until we started moving these services to different physical boxes, often even in the same subnet, that the complexity of distributed computing suddenly came to bare. We had been fooling ourselves in our development environments and in our simple deployments -with all these things on the same box it was just interprocess object oriented computing.

Unlike in CORBA and DCOM where the pain was felt immediately and profoundly, object oriented web service architectures delayed the pain until we really needed the architecture to work.

The problem is object orientation just doesn’t map well to distributed computing. Udi points out that the Gang of Four book, oft thought of as the most important pattern text, was about writing a Word Processor – a single process mammoth application.

The irony is as early as 1994 we should have known knew better. It was then that Peter Deutch drafted his assumptions on the fallacies of network computing. It states clearly the errors traditional application developers will make moving to a network model. So it is doubly sad that these became adopted by vendors as best practices. Note: Udi covers these fallacies in depth in his course.

Udi calls himself "The Software Simplist". Prior to taking his course, I had a debate with a friend over how wrong I thought that was given how complex his architecture seems to be. Post the course, I think Einstein’s paraphrased quote is appropriate. “Everything should be made as simple as possible, but no simpler.” If our object oriented patterns are not up to tackling distributed computing, then we need something more complex.

I had the pleasure of attending Udi Dahan’s Advanced SOA course this Winter. If you aren’t familiar with Udi, he’s an experienced software architect, frequent blogger, the cocreator of the CQRS pattern, and also the originator of NServiceBus. For years he has been blogging on topics ranging from DDD to SOA to the benefits of message based architectures over traditional RPC.

Udi’s SOA course is 5 jam pact days during which he works tirelessly for his students, plowing the entire 8 hours each day on his feet. Roughly half of the the course is spent massaging existing assumptions so that students can approach SOA with a new perspective. The other half is spent explaining techniques born out of years of consulting and answering a bevy of questions along the way.

When I returned to work on Monday my coworkers asked me what I had learned. I realized I had no idea where to start. This is a common problem experienced by Udi’s graduates. It’s tough to share when back with the tribe. Part of this is because Udi has his own specific definitions for widely used terms like "service" and "domain model". More though, Udi’s course is taught by Udi and lasts for five days because it takes that time and his experience to bake in these concepts. While he lets students have access to his voluminous slide deck, out of context of the talk they tend to generate confusion.

The problem is how to "scale" Udi.  There is some good news. Recently Udi has made available his entire SOA course as a series of purchasable videos. I haven’t had the opportunity to watch them; For an individual consultant they are a bit pricy, but for a corporation they are well priced and solves the knowledge transfer problem.

It’s been four months and I can feel the knowledge decay starting so I have decided to blog about what I have gleaned from it. I hope this series of posts makes you interested in Udi and in his work. Every serious architect in the .NET space should take his course not even if – but especially if you have been building systems for decades.  These posts will only be my interpretation. Go to his course or purchase his videos for the real deal.