Architecture Archives

Oct
11

How to Use NDepend’s Trend Charts

Category: .NET Tags: Architecture, Code Quality, NDepend |

Editorial note: I originally wrote this post for the NDepend blog. You can check out the original here, at their site. While you’re there, download NDepend and give the trend chart functionality a try.

Imagine a scene for a moment. A year earlier, a corporate VP spun up a major software project for his organization. He brought a slew of his organization’s software developers into the project. But he also needed to add more staff in the form of contractors.

This strained the budget, so he cut a few corners in terms of team member experience. The VP reasoned that he could make up for this with strategic use of experienced architects up front. Those architects would prototype good patterns and make it so the less seasoned contractors could just kind of paint by numbers. The architects spent a few months doing just that and handed the work off to the contractors.

Fast forward to the present. Now a consultant sits in a nice office, explaining to a beleaguered VP how they got so far behind schedule. I can picture this scene quite easily because organizations hire me to be this consultant. I live this scene over and over again.

NDepend Trend Charts

Concepts like technical debt help quite a bit. I also enlist various other metaphors to help them understand the issues that they face. But nothing hits home like a visual. I’ve described this before. Generate an actual dependency map of their codebase and show it next to the ones the architects created in Visio, and you invariably see a disconnect.

Today, I’d like to take a look at another visual feature of NDepend: trend charts. These allow you to see a graph-style representation of your codebase’s properties as a function of time. And you can customize them a great deal.

In the scene I painted for you a moment ago, the VP—and the people in his program—feel pain for a specific reason. They go far too long without reconciling the plan with reality. I come along a year in and generate a diagram that they should have looked at all along.

Trend charts, by design, help combat that problem. They allow you to get a feel for strategic properties of a codebase. But they allow you to see how that property varies with time. You can take advantage of that in some powerful ways.

Sep
19

By Erik Dietrich

Fixing Your Snarled Dependency Graph

Category: .NET Tags: Architecture, NDepend |

Editorial note: I originally wrote this post for the NDepend blog. You can check out the original here, at their site. While you’re there, have a look at NDepend’s features for helping you visualize your codebase.

I’ve written before about making use of NDepend’s dependency graph. Well, indirectly, anyway. In that post, I talked about the phenomenon of actual software architecture not matching the pretty diagrams people draw in Visio. It reminds me of Helmuth von Moltke’s wisdom that no battle plan survives contact with the enemy.

Typically, architects conceive of wondrous, clean, and decoupled systems. Then they immortalize this pristine architecture in Visio. Naturally, print outs go up on the wall, and everyone knows what the system should look like. But somehow, it never actually winds up looking like that.

Architectures of Despair

I think we all know what it winds up looking like. Or, at least, what it can look like. Sometimes the actual architecture only misses the mark by a little, around the edges. But other times, it goes sailing off in the wrong direction, like a disastrous misfire at the archery range.

When this happens, we have metaphors for the result. Work in the industry long enough, and you’ll hold your nose and describe a codebase as a big ball of mud. You might also hear descriptors involving tangled Christmas tree lights or spaghetti code. Maybe you’ll hear about a bramble bush or something.

The specific image varies, but the properties do not. All of them describe something snarled, difficult to separate, and unpleasant to work with. They indicate complexity without intent or purpose. And when that happens, deadlines slip and defects proliferate. Oh, and the people working in the codebase become miserable, now regarding those Visio diagrams as cruel jokes.

All of this stems from a core problem: a tangled dependency graph.

Sep
6

By Erik Dietrich

What Problems Do Microservices Solve?

Category: Language Agnostic Tags: Architecture, Software Strategy, TechTown |

Editorial note: I originally wrote this post for the TechTown blog. You can check out the original here, at their site. While you’re there, have a look at the tech courses they offer.

Do you find that certain industry buzzwords set your teeth on edge? If so, I assure you that you have company. Buzzwords permeate every professional space, but it seems that tech really knows how to attract them. Internet of things. The cloud. Big data. DevOps. Agile and lean. And yes, microservices.

Because of our industry’s propensity for buzzwords, Gartner created something it calls the hype cycle. It helps their readers and clients evaluate how much attention to pay to emergent ideas. They can then separate vague fluff from ideas that have arrived to stay. And let’s be honest — it’s also a funny, cathartic concept.

If you’ve tired of hearing the term microservices, I can understand that. As of 2016, Gartner put it at the peak of inflated expectations. This means that the term had achieved maximum saturation a year ago, and our collective fatigue will drive it into the trough of disillusionment.

And yet the concept retains value. Once the hype fades and it makes its way toward the plateau of productivity, you’ll want to understand when, how, and why to use it. So in a nod toward pragmatism, I’m going to talk about microservices in terms of the problems that they solve.

First, What Are Microservices?

Before going any further, let me offer a specific definition. After all, relying on vague, hand-waving definitions is the main culprit in buzzword fatigue. I certainly don’t want to contribute to that.

Industry thought leader Martin Fowler offers a detailed treatment of the subject.

In short, the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery.

Now, understand something. The architectural trade-off here is nothing new. In essence, it describes centralizing intelligence versus distributing it. With a so-called monolith, clients have it easy. They call the monolith, which handles all details internally. When you distribute intelligence, on the other hand, clients have more burden to figure out how to compose calls and interactions.

The relative uniqueness of the microservices movement comes from taking that tradeoff and layering atop it delivery mechanisms and the concept of atomic business value. Organizations touting valuable microservices architectures tend to offer them up over HTTP and providing functionality that stands neatly alone. (I make the distinction of valuable architectures since I see a lot of shops just call whatever they happen to deliver a microservices architecture.)

For example, a company may offer a customer onboarding microservice. It can stand alone to create new customers. But clients of this service, internal and external, may use it to compose larger, more feature-rich pieces of functionality.

So, having defined the architectural style, let’s talk about the problems it solves.

Jun
1

By Erik Dietrich

Bridging the Communication Gap Between Developers and Architects

Category: The Life of a Programmer Tags: Architecture, Soft Skills |

Editorial Note: I originally wrote this post for the NDepend blog. Go check out the original here, at their site. While you’re there, have a look around at the other posts and at NDepend itself.

If you want to set off a ceaseless, spirited discussion, ask a roomful of people what makes some music good and other music bad. The opinions are likely to be as spirited as they are diverse, with, perhaps, good points to be had. But consensus is unlikely.

If you want to see a similar dynamic in the software development world, ask a roomful of software developers what a software architect is. What makes a person an architect? Does the architect write code? What kinds of decisions should an architect make? What is the relationship between architects and developers? Do developers report to the architect, or is it a “dotted line” reporting relationship? Maybe they’re peers? Do architects need to have a lot of domain knowledge? Do architects need to be the best programmers (or at least have been at some point)? You get the idea.

Go out and observe enough software shops in action, and you will see every different imaginable answer to these questions in every possible combination. This fact alone lays seeds for myriad communication complexities between developers and architects. In any shop, a developer is more or less a developer. But the architect role varies widely and, as developers move from company to company, this creates confusion.

Before going further down that path, let’s consider some things that are often true of a software architect. And, I say “often true” because, as I just pointed out, the definition is fluid enough that it’s hard to pin things down definitively the way we might say, “software developers write computer programs.”

Architects tend to be the ones to make “big picture decisions” (which language/database/framework will we use?)
Architects tend to have more tenure at companies and more industry experience.
Architect tends to be a leadership role, meaning they supply either thought leadership, org chart leadership, technical leadership, or some combination.
Architects tend to have more face time with “the business” than developers.

What do all of these tendencies mean? Well, simply put, they mean that architects have somewhat of a different area of focus than software developers. Developers concern themselves primarily with the tactical, and architects concern themselves mainly with the strategic. The concept of tactics versus strategy can be (perhaps over-) simplified to the idea that strategy is the “what” and tactics are the “how.” If it comes to your personal finance, “diversification” may be the strategy and “spend X amount on stocks, Y on bonds, and Z on real estate” may be your tactics.

Apr
10

By Erik Dietrich

Visualizing Your (Real) Architecture

Category: Reasoning About Code Tags: Architecture, NDepend | 6 Comments

Editorial note: I originally wrote this post for the NDepend blog. Go check out the original at the NDepend site. Take a look around at the other posts while you’re there as well — there’s a lot of good stuff to be had.

Diagrams of software architecture have a certain aesthetic appeal to them. They usually consist of grayscale or muted pastel colors and nice, soft shapes with rounded edges. The architects that make them assemble them into pleasing patterns and flowing structures such that they often resemble 7-layer cakes, pinwheels, or slalom courses. With circles and ovals arranged neatly inside of rectangles connected by arrows, there is a certain, orderly beauty. If you’re lucky, there will even be some fluffy clouds.

If you want to see an example, here’s one that has it all. It’s even got a service bus. Clearly, the battle for quality was over long before the first shots were ever fired. After the initial conception of this thing, the mundane details of bringing the architecture to life would likely have been a simple matter of digital paint by numbers. Implement an interface here, inherit from a framework class there, and Presto! Instant operational beauty that functions as smoothly on servers as it does in the executive readout power point.

At least, that’s the plan.

DaedTech