In the previous chapter, we began looking at Azure design from an everyday working perspective, looking at examples of how to engage with customers, and then gather, map, and document requirements.
In this final chapter, we complete the beyond the exam theme by looking at what specific considerations we need to make when designing enterprise architectures.
First, we will examine two types of organization – the large-scale enterprise versus the small start-up, and how the size, age, and internal structure of a company can have an impact on our designs.
We’ll then investigate some strategies for ensuring that we get the best value from cloud solutions by looking at cost optimization techniques.
We will then explore what Azure landing zones are, and how they can help us manage the Azure platform in enterprise systems that involve multiple subscriptions and individual solutions.
Finally, we will finish off the chapter, and the book, by looking at how we might build the platform over time.
Therefore, throughout this chapter, we will explore the following topics:
- Understanding your customer
- Optimizing costs
- Creating landing zones
- Building with continual iteration
Understanding your customer
Each organization can be very different, not just in terms of goals, but also the levels of risk, security, and resilience they are prepared to accept.
To highlight such differences, it is helpful to compare two very different types of company – a well-established, multi-national corporation with thousands of employees around the world, versus a newly formed start-up, with just a handful of staff.
Looking at process differences
A multi-national company will have existing processes and ways of working that have been built up over many years. The IT department will more than likely follow industry patterns such as the Information Technology Infrastructure Library (ITIL), which is itself a framework and set of practices for Information Technology System Management(ITSM), which defines how an organization manages their IT services. In other words, larger companies generally have a set of processes that everyone must follow for managing the companies’ IT infrastructure, including implementing new services.
In addition, more staff means greater specialization for employees. Separate teams of experts will be responsible for managing specific systems, such as networking, servers, storage, security, and software development. The cloud is yet another, relatively newer addition, to the many IT departments that may exist.
How each team interoperates will be part of the IT process map. If the server team needs to build and connect some new servers, they will have to engage with the network and security teams and hand off responsibility for each area.
A small start-up will not have these well-defined processes; they will most likely be starting from a blank canvas. As a new company, they will be able to choose and adapt from a range of newer methodologies. The IT experts will most likely wear many hats – a single engineer or team could be responsible for the entire IT stack, from hardware to software and everything in between.
The larger company, in comparison to the smaller start-up, will therefore take much longer to implement new solutions as there will be a lot of coordination between teams. A new project could take months, if not years, to implement, not necessarily because of the time it takes to order and configure new systems, but because of the auditable trail of approvals that will be needed at each stage.
For example, before any new system can be built, it might go through a process of high-level design and approval by an enterprise architecture team, who will ensure that the new functionality sits in the overall IT strategy. Next, a low-level architecture will be produced and again signed off to ensure that the correct level of detail is documented, along with security and support processes. The actual build could then be handed to several implementation teams before a rigorous round of testing.
This lengthy process is there to protect the organization from wasting resources and reducing the possibility of failure, as well as implementing a system that aligns to a corporate strategy.
A smaller, more nimble company, will most likely build fast, fail fast, and iterate over many cycles when building systems. Smaller, close-knit teams can try new technologies and react much quicker to changing requirements. The overall IT strategy will most likely be much simpler and well known, which again helps everybody understand the end goal.
Smaller, younger organizations will often have IT at the core of their operations and product offering, and every member of staff will understand those technologies. For larger organizations, IT will just be one department of many, and again each department will be specialized and only have peripheral knowledge of the others.
When designing architectures, we need to consider the processes a company employs, as it will directly impact not only the complexity of any deployment but the time it takes to navigate the governance processes.
Although there is a wider movement for bigger companies to start moving toward agile ways of working, they will still be constrained in part by governance and security requirements, which we will look at next.
Leave a Reply