Architecture Over Happy Little Accidents
Technology projects are like roller coasters with their anxiety-inducing twists and turns. Some projects even feel as though success was found by accident! Yet there’s a means for smoothing out these otherwise risky initiatives, and it it’s actually a relatively low-cost investment.
Happy Little Accidents
As a child of the 1980s, television shows from the Public Broadcasting Service (PBS) channel were a prominent part of my upbringing. Even today, I can still recite the theme songs from Reading Rainbow or Mister Roger’s Neighborhood word-for-word. Yet there was one show in particular that was especially interesting: a instructional program hosted by a happy-go-lucky painter who sported an extraordinarily puffy hairdo. I’m of course referring to Bob Ross and his TV show: The Joy of Painting.
I found something intriguing about Bob Ross, and others of my generation shared this sentiment. Unsurprisingly, parodies of Mr. Ross began to take off; the earliest of which I recall being composed by MTV, which really foreshadowed the eventual explosion of Bob Ross mockeries that would materialize as animated GIFs and “meme generators” which became part of everyday Internet for the generation that came of age during the turn of the century.
Here’s the amazing thing about Bob’s style: there was no right or wrong. An accidental smudge of the brush could easily be massaged into a pine tree or perhaps a puffy cloud. In the end, it was all just art and Bob would never judge a student who figured things out as he or she painted along.
Not so Happy Enterprise Accidents
We don’t build homes by picking up random pieces of lumber and being nailing them together. Yet with many technical projects, enterprises haphazardly commence large-scale initiatives with just a vision and a budget. These two ingredients are a good start, but without a disciplined formulation of the solution, a gap emerges between strategy and execution. Whether your execution arms consists of full-time employees, contractors, or both, the teams need formalized views of the solution. Otherwise, the process becomes subjective.
Like the artistic painter who paints in broad strokes, often re-working areas of the canvas over and over until her final image emerges, the road to success is repetitive and highly individualized. Such practices are wasteful and emotionally taxing. Still I can’t help but see the comical similarities to the Bob Ross school of thought: an elongated string of “happy little accidents” which eventually morph into a usable solution after many (painful) iterations of re-work.
Don’t get me wrong, some iteration is healthy; especially with software engineering projects. Intentionally small scope, combined with agile sprints and frequent feedback is a great way to build applications. But large-scale, cross-functional enterprise projects are a different horse of a different color. Such endeavors require greater rigor around specifying what is to be built, and by whom. To exemplify this point, I’ll use two simple examples.
1. The Lead Generation Project
Many organizations want to raise top-line revenue by acquiring new customers, which of course requires cultivating new leads and prospects. But stuffing the top of your marketing funnel does no good if the sales team isn’t ready to accept, score, and process those leads. Who is making sure that the cross-functional orchestration of business processes and tooling is properly coalesced? Do the sales and marketing teams have a shared understanding of the vision? Do they have enough detail to build a functional solution?
Without architecture, you don’t have a well-oiled machine. Instead, two groups work against each other with misalignment and copious amounts of friction.
2. The Analytics Program
Data rarely lives within the confines of a single team. Instead, it’s typically generated by one group, collected and transformed by a technical team, and finally consumed and analyzed by a business audience. All too often these groups are disjointed and lack a shared vision of end-to-end data value.
Without an overarching vision around tooling and process, the only guarantee an enterprise can expect is one of multiple data practices, silos of redundant tools and staff, and worst of all: ambiguous definitions of data which nobody mutually agrees upon.
Ultimately, “happy little accident” projects are completed through a combination of trial and error along with sheer brute force. Tell-tale symptoms of projects that lack supporting structure includes finger pointing such as “poor vendor execution” or "immature development teams." It’s basically everyone’s problem, and there’s seemingly no one easily identifiable culprit.
Of course, there is in fact a smoking gun. And it’s a lack of architecture.
But We’ve Lived Without Technical Architects Thus Far
Before I discuss the solution to many of these enterprise ailments, let’s get one thing out of the way: whether or not an organization can “live with” or “live without” formal architecture expertise.
First of all, enterprise customers don’t always know what they need; especially when they haven’t experienced the value of a particular service in the past. History explains this tale well, as plenty of people didn’t see the need for cars when they had horses. High-definition televisions seemed excessive when standard-def TVs were the norm, and who needed a “smartphone” when you got along just fine with a simple flip-phone?
I can summarize thusly: you can in fact live without an architecture discipline. You can also poke a tiger, or steer a car with your feet. That sure as heck doesn’t mean they're good ideas! The point I’m trying to make here is we should be striving to make our work lives easier; not maintain the status quo.
Practical Examples of Technical Architecture
If chaos is the disease that grinds important projects to a painful halt, architecture is undoubtedly the penicillin. Architecture is the bridge between resources (think money) and execution. Brawn is useless without brains, and architecture provides your enterprise execution muscles (such as staff or managed service providers) with much-needed specificity around what to build, by whom, and by when.
So what do these architectural artifacts actually look like? There are endless examples, but some common go-to items include:
Capability maps - Architecture isn’t always specific to a particular process or technology. In fact, “enterprise architecture” is an entire discipline devoted to macro-level (enterprise-scope) architecture. That means examining what the organization does today, looking at potential future opportunities, and what capabilities the organization needs to build in order to address potential gaps.
Capability maps are an excellent starting point for determining where to focus strategic initiatives or mitigate major corporate problems.
Roadmaps - How will you know if you’ve arrived at your destination if you don’t even know where you’re going? This sounds silly, but many organizations simply follow wherever the road takes them.
A roadmap is not a project plan, but rather a means of describing what enterprise customers should expect to receive over a period of time. A sales and marketing roadmap may explain that a unified lead generation process is delivered in the next two quarters. A finance roadmap may show procure-to-pay automation value delivery over the next year. An information technology roadmap may show the steps in delivering self-service cloud computing to engineering while simultaneously driving down data center costs.
The Enterprise Application Portfolio - Today, every enterprise department is a technology department. From finance to engineering, all divisions boast a blistering array of cloud applications and data, and none of these solutions reside in a vacuum. Rather, these solutions are part of a enterprise-wise ecosystem which either peacefully cohabitates or aggressively competes for resources like an invasive species.
Examining applications as a portfolio means taking a holistic approach to application management. Similar to the way a financial advisor balances a mutual fund of investments, decision makers must also understand what applications they today have before they go out and make additional software investments. This may sound ridiculously simple, yet almost every day I see situations where companies support a dozen different chat tools, fumble with five or more different customer relationship management (CRM) solutions, or struggle with integrating multiple web stacks. Without a holistic management strategy, the problem only worsens.
In the technical world great architecture comes in many forms, yet the outputs are always the same: better visibility, better decisions, and smoother projects with higher degrees of success.
Architecture Transforms Chaos into Calm
Without architecture, there’s an almost guaranteed descension into chaos. Yet with architecture, people have a shared understanding of the solution, and are thus enabled to work towards achieving that vision with a fair amount of autonomy.
Architecture enables us to precisely articulate what the project, program, or overall organization needs to build so that ambiguity and confusion are minimized. In a way, architecture is the glue that holds complex projects together. It's the solidified vision that gets (and keeps) everyone on the same page.
Of course it’s possible to complete a project without an architecture discipline. Though the investment in architecture is relatively small, and its returns are significant. Without an architecture discipline, projects often take longer, cost more, and boast higher rates of employee and contractor churn.
As a major stakeholder in a corporate project, you need all the clarity and assurance you can get, and architecture delivers on that promise. While I label this as architecture, others simply call it peace of mind. Either way, we all can agree on one thing, and that’s leaving the happily little accidents to the free-spirited artists like Bob Ross.