Being part of the VMware Community is one of the most important career decisions I have ever made.
The opportunities and connections this program has provided me over the years have been amazing.
Thank you to all in the program and it’s great to be part of it for another year.
I recently had the pleasure of presenting in the main room at the National Space Centre in Leicester.
It was great to be at an in-person event and have the opportunity to discuss new design patterns and use cases with VMware Cloud Solutions such as VMC, AVS, and GCVE.
As mentioned, my summary mind map used at the session is available here
I have just arrived back from San Francisco having spent a week in the Multi-Cloud Universe known as VMware Explore.
It was great to be attending in-person and to have the honour of presenting on a variety of topics – Multi-Cloud, VCF 3 to 4, and vSAN.
It was awesome to see friends and colleagues from all over the globe and to deep dive into technology for a few days.
As promised in my sessions I have posted my developing multi-cloud content here
Having a long-term strategy to provide value while meeting specific design requirements is always a focus for a solution architect.
With multiple concerns such as datacenter containment, power costs, support dates for each software layer, sustainability goals, and ever-increasing new features, it is easy to design for the immediate requirement and what is needed now without considering the future business risk or operational impact ahead.
In the highly competitive cloud world, features change, develop and so do the costs. The introduction of a feature that seems to be an answer to your specific business problem could be changed, even deprecated, or potentially lock your business into a situation where you cannot consume another service elsewhere. In addition, the location and control of data depending on the content is also an important focus (ie sovereignty, competitive partner relationships).
When reviewing requirements with a business, an architect can use this time to understand the appetite and landscape of risk and the need for flexibility. These long-term aspirations are also an important design factor.
A seemingly simple datacenter consolidation project (i.e., “We want to get out of the hosting datacenter game”) could also have hidden assumptions (i.e., “Once we move to the new platform, we don’t want to be tied to any particular vendor relationship, we want to maintain the ability to financially negotiate, and control our data location. At the same time, being cloud-like in new applications”).
A long-term strategy will also likely involve multiple technologists, potentially SMEs, and vendors with differing views/focus on specific layers.
How does an enterprise-focused architect for a business ensure consistency of approach, and control risk/understand operational requirements going forward?
The value of infrastructure agnosticism was a subject of a recent panel discussion webinar I was kindly provided the opportunity to be part of (Thank you, John Marrone).
The concept of providing a simple consistent platform for applications while respecting business requirements such as locality, current operational skill-set, budget, and security is not new.
This end-state is often faced with more and more competing design factors especially as you hand over some of the responsibilities (ie Operating system/hardware) to a provider. Yes, you have an SLA and expectation/understanding of a platform you may not have had before in a self-run platform but at what cost/risk?
You may find a very important business service is now tied to a specific cloud service at a hyperscaler that has an interdependency with another business application that you feel should sit in a different cloud service for licensing or support reasons. What are the options? Refactor costs again? Migrate one, pay more? Modern examples of standard technical debt.
This type of challenge, for me, is helped by considering the impact, and ensuring abstraction/features are applied at the right time for a business. Normally at the conceptual and logical phases of enterprise design.
In this example, the logic of the business expectation can be reviewed and applied to a vendor-specific technology. The agreement of specific landing zones mapped to business characteristics and relationships can aid discussion and future design decisions/amendments.
Logical designs such as this can also be used by an enterprise architect to help shape conversations and ensure consistency in approach with the multi-technology SMEs.
Physical diagrams mapped back to business logic and requirements can help ensure cloud features are mapped to business needs and the logical strategy without increasing complicity. Each feature or core service is justifiable and risk assessed to ensure the safety of project service or data.
For example;
This approach of design rationale review, feature consideration, and justification with impact analysis can remain constant throughout the assessment of technology. From the on-premises exit, migration wave planning to new strategic PasS service consumption.
Providing a consistent approach for a solution architect in an ever-changing cloud world.
Recently, I transitioned to a new role. I am now very happy to be working as a Principal Architect with a focus on Multi-Cloud Architecture.
From an architect’s perspective, my interest is always the customer/partner business value, how to identify and develop their requirements into a technical logical design, and then understand the decisions that need to be considered for successful deployment and consumption at scale.
How should an enterprise architect approach the Multi-Cloud World ?
* Major Pillars of the VMware Cloud Ready Framework
The amount of information available within technology is potentially overwhelming for any technologist.
How should an enterprise architect even get started?
There are standard design methodologies, alongside vendor-based recommendations for strategies. Technical documentation, videos, books, webinars, and free tiers/credits everywhere? Which one is best?
“Absorb what is useful. Reject what is useless. Add what is essentially your own.“
Bruce Lee
From a technologist’s point of view, understanding the technology and the features/capabilities is extremely interesting and valuable. It could, however, be very easy to go down a rabbit hole and be lost forever in reading about interesting cloud features that are not relevant to your business.
Understanding the business use case and requirements is key to success. By developing the criteria and ensuring it is able to be practically measured, the initial desired logical state model can be created.
Once the initial logical design has been established, the business to technical decisions are easier to understand and discuss.
With a business requirement-based logical design, the vendor documentation and content review for whatever technology or cloud provider/service becomes easier.
The requirement, to feature, to design decision mapping can be more tightly focused and a service design can be developed with areas such as cost optimization, sizing, capacity, connectivity, security, and sustainability considered at the vendor technology level.
What are the risks and the gaps with the business and service design for operation, and successful consumption?
This is an important area, in which I am particularly interested for my advisory activities as an architect.
Creating the transition states and ensuring a business impact analysis is constructed while navigating a journey to something like a multi-cloud solution can be extremely valuable.
This activity can provide real business insight with areas of operational understanding, and practical ability to migrate or transform applications/workloads.
Design frameworks are extremely useful, but how to apply them while understanding the business impact is an important skill that I am always looking to improve.
Useful Links
VMware Cloud Ready Framework – https://vmc.techzone.vmware.com/vmware-cloud-ready-framework
AWS Well-Architected Framework – https://aws.amazon.com/architecture/well-architected
Google Cloud Architecture Framework – https://cloud.google.com/architecture/framework
Microsoft Azure Well-Architected Framework – https://docs.microsoft.com/en-us/azure/architecture/framework/