by Betsy Burton

The SolarWinds hack was bad and it is having a growing impact on the IT ecosystem at large. As an enterprise architecture (EA) practitioner, I have long questioned EA practitioners and CIOs about how much they are applying enterprise architecture practices to the internals of their cloud-based service and COTS on-prem solutions and applications. The response I almost always get is that they do not directly apply EA practices to the internals of cloud or on-prem solutions because that's what their provider is supposed to do.

To be honest, this response never sat well with me, as it places a lot of faith in the hope that your service/solution provider is proactively ensuring that their services are adhering to solid architectural policies and principles. What I find is that organizations include their use of a service/product in their EA discipline; but not the internal architecture of these services/solutions.

The Solarwinds Hack

Watching the news regarding the SolarWinds hack brought home to me in a very clear way why it's important for organizations to architect their ecosystem, not just their enterprise.

Do Your Service/Product Providers Adhere to Your EA Policies and Principles?

I am pretty confident 90+% of you reading this blog would say “…I don’t know.”

When we evaluate services and products, we are generally focused on the features and capabilities they provide our business, not the degree to which the provider is architecting a scalable, reliable, secure, and extensible internal architecture. And equally important, do they have the policies and principles in place to ensure their scalability, reliability, security, and extensibility over time?

And, even further, I would bet that most cloud service providers and solution providers don’t have a deeply defined architecture that they could share with customers, let alone documented models, principles, policies, and roadmaps.

Enterprise architects must take into account the entire architecture of their ecosystem to avoid risks.

Architect Your Ecosystem, Not Just Your Enterprise

Since so many organizations have become completely dependent on highly distributed cloud-based services and solutions, it is imperative that they expand their EA discipline to include their ecosystem of application, services and information providers.

This means:

• Including the internal architecture of providers’ solutions and services in EA diagrams (contextual, conceptual, logical, and implementation levels). This means organizations must require that their services/product providers support clear and up-to-date architecture diagrams.
• Ensuring that you have clearly documented policies and principles for ensuring scalability, reliability, security, and extensibility, and that your services/solution providers are adhering to these policies and principles.
• Integrating your solution/product providers roadmaps into your EA roadmaps. And, not just at a high level, but rather roadmaps must include specific enhancements, fixes and integration plans.

Another Benefit of Architecting Your Ecosystem

Regardless of how hard we try we are likely to not get a complete picture of your solution/product provider’s internal architecture. But it should be where your EA efforts are expanding. And, even if you don’t get that complete and transparent understanding of how your service/solution provider is architecting their offering, it is still worth including as much as possible in your EA discipline.

The more you include service/solution providers internal architecture in EA, the more your organization will be prepared to determine the impact and address issues quickly in the case of an issue (hack, failure, integration, etc.). Don’t let your services/solutions become a black box that don’t enable you to quickly respond to issues.

Bottom Line

In today’s highly distributed technology landscape, architecting your enterprise (EA) is not enough. Organizations must architect their business ecosystem (EcoA).

End User Organizations:

• Be prepared that most services/solution providers will not be able to provide their internal architecture beyond a conceptual level. However, organizations must start now to demand this information from their providers, so that they begin to understand that it is a requirement to document and provide this information.
• Socialize ecosystem architecture across your business and IT. Consider updating your EA charter, roles, and scoping documentation.

Technology and Solution Providers:

• Services/solution providers that are rearchitecting their offering based on a common platform should use this time to begin to create architectural documentation (models, principles, policies, and roadmaps) that can be shared with customers.