Customer Lifecyle Architecture

If you've gone through any "intro to cloud development" presentations, you've seen the argument for cloud architecture where they talk about the needs of infrastructure scaling up and down. Maybe you run a coffee shop bracing for the onslaught of pumpking-spice-everything, or maybe you're just in a 9-5 office where activity dries up after hours. In any event, this scale-up / scale-down traffic shaping is well-known to most technologists at this point.

But, there's another type of activity shaping I'd like to explore. In this case, we're not looking at the aggregate effect of thousands of PSL-crazed customers -- we're going to look at the lifecycle of a single customer.

Consider these two types of customers -- both very different from one another. The first profile is what you'd expect to see for a customer with low aquisition cost and low setup activity -- an application like Meta might have a profile like this, especially when you expect users to keep consuming at a steady rate.

Compare this to a customer with high acquisition cost and high setup activity -- this could be a customer with a long sales lead time or one with a lot of setup work, configuration, training, or the like. Typically, these are customers with a higher per-unit revenue model to support this work. Examples of a profile like this could be sales of high-dollar durable goods, financial instruments like loans, or insurance policies, and so on.

So, What?

Why, exactly, would we care about a profile like this? I believe this sort of model facilitates some important conversations about how a company is allocating software spend relative to customer activity, costs, and revenue, and I also think an understanding of this profile can help us understand the architectural needs of services supporting this lifecycle.

Note that this view of customer activity has some resemblance to a discipline called Customer Lifecyle Management (CLM). Often assoociated with Customer Relationship Mangement (CRM), CLM is typically used to understand activities associated with acquiring and maintaining a customer using five distinct steps: reach, acquisition, conversion, retention and loyalty.

Rather than just working to understand what's happening with your customer across the time axis, consider some alternative views. We can map costs and revenue per customer in a view like this, for example. Until recently, the cost to acquire a customer could be known only on an aggregate basis - computed based on total costs across all customers and allocated as an estimate. But as finops practices improve in fidelity and adoption, information like this could become a reality:

FinOps promises to give us the tools to track the investment in software you've purchased, SaaS tools, and of course, custom tools and workflows you've developed. Unless these tools are extremely mature in your organization, you'll likely need to allocate costs to compute these values. Also note that these costs are typically separated on an income statement - those occurring pre-sales tend to show up as Cost of Goods Sold (GOGS), while those after the sale are operating expenses (OpEx), and if you intend to allocate COGS, these will need to be interpolated, as none of the customers you don't close generate any revenue at all.

Less commonly considered is the architectural connection to a view like this. You might see a pattern like this if you're writing an insurance policy and then billing for it periodically:

Not only do these periods reflect different software needs, they also reflect different oppportunities to learn about your customer. Writing a new insurance policy is critically-important to an insurance company -- careful consideration is made to be sure the risk of the policy is worth the premium to be collected. For that reason, an insurance company will invest a lot of time and energy in this process, and much will be learned about the customer here:

On the other hand, the periodic billing cycle should be relatively uneventful for customer and carrier alike, and less useful information is found here -- at least when the process goes smoothly.

I believe the high-activity / high-learning area also suggests a high-touch approach to architecture. Specifically, I think this area is likely where highly-tailored software is appropropriate for most enterprises, and it also likely yeilds opportunities for data capture and process improvement. Pay attention to data gathered here and take care not to discard it if possible. Considering these activity profiles temporally may also lead us to identify separation among services, so in this case, the origination / underwriting service(s) are very likely different from the services we'd use after that customer is onboarded:

What's next?

I'm early in exploring this idea, but I expect to use this as one signal to influence architectural decisions. I expect that an acvity-over-time view of customers will likely help focus conversations about technologies, custom vs. purchased software, types of services and interfaces, and so on.

At a minimum, I think this idea is an important part of modeling services to match activity levels, as not all customers hit the same peaks at the same time.

What is Craftsmanship?

I was asked recently to define "craftsmanship" in software development, and I thought this would make a great topic for discussion.  You can obviously find a dictionary definition for craftsmanship, but much like with architecture, I think that when we attach the additional context of software development, craftsmanship introduces some important ideas about how individual contributors fit into a larger software development organization.

Software as Art

IMG_5891.jpg
Ladle (Photo credit: lambertpix)

The concept of craftsmanship in general emphasizes the skills of individuals, and connotes high-quality, highly customized work.  It is very much the antithesis of mass production.

This general understanding, when applied to software development, implies a very individualized experience -- indeed, if you think about buying a work of art or even something like a piece of furniture, "craftsmanship" would imply that the product you're buying is one-of-a-kind.  Nobody, literally, has another item quite like the one you're buying.  For businesses commissioning custom software, there's a nugget of truth here, of course -- one of the reasons to write custom software is the presumption that your business requirements are different in some way from everybody else's requirements, and your business demands the flexibility that comes with custom software.

Another key aspect of craftsmanship is the deep and broad skill set of the craftsman.  Just as you'd expect a hand-crafted product to be almost entirely the result of one man's work (to the extent that signing the work wouldn't be unheard-of), so software craftsmanship emphasizes individual skill and accountability.  And while craftsmanship doesn't necessarily imply apprenticeship, a craftsman is certainly expected to be highly experienced and able to draw on years of work in the field in order to produce the sort of high-quality work that's expected.

Business Implications

While high-quality, highly-customized software sounds very appealing from a business perspective, the deliberate pace and unyielding attention to detail we most often associate with craftsmanship is petrifying.  Business software needs to move at the pace of business, after all, doesn't it?  I really believe that the implied slowness of craftsmanship acts as an impenetrable stigma against its adoption, which I think is largely unfortunate.

One of the key benefits of the higher-quality code produced by accomplished craftsmen is that less time is spent on an ongoing basis recovering from the sins of shoddy coding as these systems grow and evolve over time.  High-quality code not only works better, it's more maintainable, so that initial effort can pay real dividends over the life of a long-lived system.  Where we sometimes talk about sloppy code as being high in technical debt, quality code can be seen as an asset for an organization.

Right now, software craftsmanship remains on the fringe of development practices, and thus tends to be favored in smaller shops, as well as in "green-field" projects much more so than in larger, more established environments.  It remains to be seen whether it eventually transitions into mainstream use the way that Agile has, but I think a lot depends on the effective communication of the real benefits of craftsmanship, as well as on mature tactics to introduce and manage craftsmanship in the organization.

My Take

Craftsmanship is about individual contribution.  It's about taking pride in your work, and it's about a relentless journey of improvement.  The scope of these experiences is best-suited to small groups of developers who can help one another grow and hold each individual accountable to the group.  This, all by itself, is a tall order.  It's not easy for anyone to expose himself to criticism, and that's a huge prerequisite for this sort of culture to form.  This sort of open sharing takes huge amounts of trust, and trust takes time to build.

IMG_8296.jpg
(Photo credit: lambertpix)

Another critical motivator for a "craftsman-like" organization is the sense that the team is building something that's going to last.  When you think of hard goods built by craftsmen, you equate the higher quality to a longer lifespan -- as a consumer, you may be willing to pay a premium for a product that will outlast a cheaper product because you know it'll last a long, long time.  In software, this understanding of quality has to be visible to the team as well as the customer, and the team needs to believe that this higher quality is valued.  Few things are as demotivating for a developer as seeing a great body of code mangled by someone who doesn't share the same capabilities or desire for quality.

It might seem at this point that I'm advocating an all-or-nothing strategy for software development, or that software craftsmen can exist only in small shops, but I don't believe either of these is necessarily true.  I believe that if craftsmanship is going to exist in a large organization, however, the organization needs to understand where it's going to be applied and it must organize its teams to support craftsmanship in targeted areas.  I think this prerequisite is well-suited to a component-based Enterprise Architecture, in which well-defined components or services are identified, invested in, maintained with care, and protected, and yes -- this demands an enlightened and skilled application of Enterprise Architecture.

Craftsmanship isn't a magic wand, or a buzzword, or a slogan.  Craftsmanship takes hard work, and it demands commitment from organizations and developers.  It's not right for every organization, and it certainly isn't right for all developers, but if you need software that stands the test of time, craftsmanship will pay dividends for the lifetime of that software.

The politics of software

This fall, as healthcare.gov imploded before our eyes, we saw any number of self-proclaimed experts chime in on why it coughed, sputtered, and ground to a halt, and how, exactly, it might be fixed.  My guess is that the answer is more complicated than most of them let on, but I'll bet there's a healthy dose of politics mixed in with whatever technological, security, and requirements issues might have surfaced along the way.

IMG_6589.jpg

It seems somewhat counter-intuitive to talk about politics at all in the context of software development, of course.  One of the aspects of software that really appealed to me when I entered this field was that for most problems, there existed an actual correct answer, and there are no politics in algorithms.  Ah, to return to the halcyon days of simple problems and discrete solutions!

Today's problems are more complicated than ever before, though.  Prodigious capabilities have bred complex systems and murky requirements under the best of circumstances, and no government project operates under the best of circumstances.  For those of you in private enterprise, you surely are aware of the struggles bred of competing interests and limited resources, but in a government setting, all those factors explode.  Funding is rarely connected directly to stakeholders, opinions are everywhere, and "deciders" are nowhere to be found.   Not to put too fine a point on this, but if we were to think of government-sponsored software as having been congealed rather than developed, we might be on the right track.  It's actually a small miracle when these systems work at all, given the confluence of competing forces working to rip projects in seventeen directions at once.

Think back for a moment on the early days of Facebook or Twitter or any of the other massive applications that serve as today's benchmarks of reliability.  They weren't always so reliable, of course.  Twitter, in particular gave birth to a famous "fail whale" meme in 2009 as it sorted out its capacity and reliability issues.  To be clear, twitter operates on a huge scale, but all it's doing is moving 140-character messages around -- there isn't a whole lot of business logic there, short of making sure that messages get to the right person.  It's pretty easy to gloss over some of those growing pains, but virtually every large system has them.  In the case of healthcare.gov, the failures happened under the hot lights of opening night and amid opponents who wanted desperately to see the system fail, and fail hard.

If you work amid politics like this, I'd love to offer a simple solution, but sadly, I have none.  Instead, I'd urge a little empathy; walk a mile in the footprints of developers, project managers, analysts, and testers on projects like this before you criticize too vigorously.  I can assure you that if you think this was a failure with a simple cause, you're mistaken.

Related articles

 

 

Enhanced by Zemanta