What is an Enterprise Architect, or a Cloud Architect, or a Software Architect?
Many people think it’s just a fancy title, something to show that someone is more senior than a senior developer or a principal developer, but not necessarily a manager. A great example is Bill Gates; when he retired from Microsoft his title was Chief Software Architect.
But architecture actually has a pretty formal definition that means something specific, and is critically important in organizations above a certain size.
OK, so what is architecture then?
Architecture is about the art and science of building things. It’s the keystone for how things are constructed. The blueprints, if you may. And it’s the enabler to see what all the components of an enterprise system are, and how they work together.
So how does that work?
In the formal pedantry of architecture, much of this information is codified and communicated with various artifacts. You have Views, which are the types of drawings or artifacts that you have in your architecture, and then you have Models which are the actual implementation of said Views, for your system.
An example: A View might be a network diagram template, which explains and defines the types of icons and lines you would have in your drawing. Your Model is then your actual network diagram. But Views and Models dosn’t have to be just drawings. Your View could be Javadoc, and your Model your automatically-generated Javadoc files.
All right, so we’ve established this overly-formal definition of architecture. But why is this important? Why do all these Views and Models need to exist?
There’s actually a myriad of reasons:
- Everyone knows what the components are in the system
- Everyone can tell where their component boundaries are, where their project or line of responsibility begins and ends, and thus where the interfaces they are responsible for consuming and producing exist
- You can then map specific requirements, use cases, constraints, and assumptions to specific components, so people understand what they have to do
- You can show what the specific interfaces between components are, so people can write their code or build their system properly
These really all distill down to the same key function: Communicating a vision to everyone. So that everyone can make sure their stuff works together and they are moving in the same direction all together.
Another important responsibility that the architecture can provide is support for ops. Not only for troubleshooting, but for helping ops understand where to implement monitoring, automation, and maintenance processes.
So let’s say you’re an architect, and you’re tasked with performing this critical function in your organization. What is it you actually do?
First and foremost, you are responsible for developing and maintaining said models.
That doesn’t necessarily mean you go build them all yourself. It might mean you oversee and delegate the development of the artifacts to a team, or help roll the Views/templates into the engineering processes and milestone gates.
How do I do that?
This could mean you are modeling what exists and working with teams to ensure their designs work together. There might be known issues with integrations and interactions across the enterprise, and building the “current, as-is” architecture is what is needed to understand the challenges so they can be addressed.
This could also mean you lead the process to decide what the planned, “goal” models should look like. You can work with various project teams to help them define the desired end-states of their products and services, and then validate that all the architectures will integrate together properly.
I encourage you to take a look at some popular and common view frameworks. My personal favorite is the Kruchten 4+1 framework. The DODAF is also popular (and even required) in certain industries.
As you can see, architecture is more than just a fancy job title. It is a critical function for large organizations and complex systems, and can be a huge driver and enabler for success.