Many individuals have asked what I do, and the answer varies depending on who is asking. It’s usually either a generic “I work in IT”, or a detailed explanation, because very few people have heard of a Service Maturity Architect. Here’s my written attempt to explain what this niche role is, and why it’s critical to companies, especially those currently growing into mature enterprises.
As a start-up, you’re moving fast, trying to produce a product that is going to stick in the marketplace and be successful. Like it or not, features are king, and behind-the-scenes can suffer neglect. The main thing is that the gears are moving and your customer base is growing. This worked for years in the software industry, but then four things happened (or are currently happening):
- On-premises, perpetual software gave way to cloud with a subscription model and focus on ARR
- Domestic and international privacy laws matured
- National sovereignty and international distrust
- Global distrust of supply chain issues and compromised trusted vendors
In the first scenario, as products move from perpetual licenses and on-premises bits to cloud-hosted, subscription models, the operational burden moved from the customer to the provider. Gone are the days of shelfware in on-premises environments bringing in revenue. Gone as well is the loose operating models for cloud environments. A new era of standardization and discipline is required, as customers require industry-standard attestations of these disciplines via vehicles such as ISO and SOC. In the second case of privacy laws, such as GDPR and CCPA, new concerns (and significant financial risk) arise around special treatment of personal data, which is largely a foreign concept to most engineering and operational teams. These 2 things have happened, 2 more are currently playing out.
The first of these currently emerging aspects is the global decoupling due to growing distrust and conflicting political drivers, moving towards a fervor for regional and/or national sovereignty. With the current geopolitical scene it’s not unexpected, and I suspect it will grow dramatically in some areas over the next couple years. Impacts are far-ranging, from revenue loss as you can no longer have as many economies of scale, to renewed focus on export controls, sanction enforcement, etc. Last, but certainly not least, the hack of Solarwinds and use of a legitimate product to spread malware caused a final tipping-point in the issue of implied trust. Now, not only are industry-standard certifications required for operational disciplines, but source code contents and development practices are also subject to contractual terms, which usually include the term Software Bill of Materials (SBOM). Software isn’t what it was a couple years ago. In this quickly-changing world of geopolitical, legal, supply and other environmental factors, the Service Maturity Architect comes into play.
If I was to choose the top three skills required in this role, they would be an ability to see the strategic picture, an analytical mind (much like an auditor), and an ability to understand technology enough to plot an immediate course forward. This is where we come in, a highly trusted a jack-of-all-trades, master-at-none, but focused on maturing processes, procedures, and tools to allow the business to pivot on maturity as quickly as possible. Remaining effective as the pivots are taking place with the larger picture in mind, while still remaining focused on tactical changes to get the business to the proper position. So many people get lost in the strategy and can’t execute on the tactical, or get lost in the tactical and lose focus of the strategic, which leads to a solution that doesn’t fit the end goals. This activity is much like any other architect’s duties, however the difference comes in the vast expanse of areas we are involved in. A security architect will bring about best practices, such as the NIST Cybersecurity Framework, CIS Critical Security Controls, or various NIST standards such as 800-53, to identify owners, assets, and applicable controls. A Service Maturity Architect does the same, but for areas as diverse as U.S. export control laws and sanction response, legal and contract negotiation processes, portfolio hierarchy, standardized engineering practices and standards, build and source code provenance, etc.
Throughout this process though, it’s been re-enforced for me the truth that is in the words of Jesus when he said:
“He who is faithful in a very little thing is faithful also in much, and he who is unrighteous in a very little thing is unrighteous also in much.
Luke 16:10
I don’t recall the author, nor the direct quote, so credit cannot be appropriately applied, but it’s still worth sharing. The best companies are the ones that do the basics correctly. If you don’t value the basics, if you’re always accumulating technical debt without a concerted effort to remove it then this proverb certainly applies:
The rich rules over the poor, and the borrower is the slave of the lender.
Proverbs 22:7
As we’ve seen with the recent rate hikes and failure (or decline) of many tech companies, you can take a poorly run company a long way on free capital. However, once troubles hit, these ones quickly fade from the scene. The opposite is also true, if you are running an undisciplined organization, you will be unable to scale with immediate success. My favorite example of this is Zoom, which became a household name, almost overnight, as COVID entered the scene. They appear to have survived the test of immediate success, and were able to scale with it, much to their benefit! Others have not, or will not fare as well as their journey progresses.
Do you want to have a mature organization? Are you desiring the ability to scale well and provide reliable services to your customers? If so, focus on the basics.
Are you desiring the ability to scale well and provide reliable services to your customers? If so, focus on the basics.
Ensure you have defined processes that are not burdensome; accompanied with automation to guide your users along. Know your environments, data and metadata. Map them together and establish clear paths of communications and dependencies between systems. Make it clear and easy for users to know where authoritative data lives, and how to manage it. Then, continue to make it reliable through clear ownership and accompanying responsibilities. If you find yourself doing this in every area across the enterprise, you’ll look in the mirror and realize that you are a Service Maturity Architect.