A different style post today. Its hard to strike the right balance between process and delivering results. I've been thinking about how I would explain what I do on a daily basis. I like the excitement of delivering results, another happy customer, creating a new tool, script, solution design or doing whatever it takes to get the job done better next time, and don't particularly care for process. Sometimes its hard to even justify taking the time to define process.
I think most people who work in IT for some time have a hard time explaining what they do, and have a hard time keeping track of what they did yesterday. But part of the job is ensuring that what we do is informed, documented, and easily repeatable. This means getting rid of as much busy work as possible. Ultimately the goal is that we and the teams we work with make time to learn and improve every day.
Enterprise Architecture (EA) exists to create building blocks, a foundation if you will, upon which to build a technology stack that directly supports business strategy. Traditionally it feels like Enterprise Architect practices focus on the long-term, and perhaps even, that the concept of defining high level processes and guidelines actually slow down business operations. After all, more process is usually bad right?
Much like a traditional architect, most of the job involves asking questions, and designing based on requirements, limits, constraints. Just like asking, "Does this beam have enough strength to support this structure?", and "Will the structure be durable, look and work the way the customer wants?" one asks questions like:
- Does the customer actually need this?
- Will this solution still suit in five years time?
- How will we handle data transfer between different business applications?
- Can we move data and workloads if one cloud platform or software offering becomes more affordable or reliable than the other?
- Is it possible to always use the latest features each provider offers, without creating irreversible lock-in?
By offering consumption based models, where you can scale near-infinitely on-demand, and pay-as-you-grow, cloud adoption allows businesses to remove a lot of the up-front commit they might have spent on infrastructure, and offload a lot of the heavy lifting involved in daily maintenance. The effort to maintain infrastructure can often be reduced to near-zero, especially when using containers, or serverless. By consuming services that are built on learnings from other customers, cloud providers are often able to provide far better solutions than any one individual business would be able to manage. One would almost argue that less IT governance is required now that the cloud provider performs a portion of the work and you can instantly provision services. But there is still a need to document and track learnings on an organizational level.
Information technology is usually a wild west, where a balance has to be struck between security, new functionality and keeping the lights on. For some organizations, this needs to happen at a budget that is cut at a rate of 10% per year. Having things be fast and good and cheap at the same time, isn't exactly easy, usually it's quite impossible. And knowing where to make the right trade-offs requires learnings that don't happen over night.
The amount of available technology and cloud offerings boggle the mind. As your systems are more spread out than ever, distributed across multiple cloud providers, headquarters and branch offices, documenting your design decisions, existing environment and changes that take place over time is more important than ever. This will inform design decisions the next time around.
Enterprise architecture, and technology architecture disciplines as a whole try to add a level of formality and structure, not to impede progress, but to ensure that every time something is learned about an environment, these learnings make it into the next project, and that when something is implemented, that it will sustainably function for the duration of that implementation's life cycle. Architecture frameworks that define patterns and processes to go through during technology implementation can be quite complex. They can probably be boiled down to this:
- Document your work.
- Understand the scale and scope of the task at hand, both on a technology and business level. Ask as many questions as you can.
- Find out who may have a vested interest in this project, and who might take a bit more convincing.
- Define standards and requirements around security, reliability, manageability, performance, and cost.
- Test before implementation and know the point at which a solution breaks so you can design within limits and constraints.
- Use automation and self-documenting tooling wherever possible. Track changes over time and recognize patterns to improve the implementation for next time.
- Learn from other people's technology stacks, best-of-breed implementations and share when you can. There is no need to reinvent the wheel, no matter how exciting that can be, if you don't have to.