What does an evolutionary architect do?
You’ve probably heard of all kinds of architects ranging from enterprise architect to solution architect. But an evolutionary architect steps up the game and leads the way in terms of making sure your component are future proof. But how?
We’ve coined the term, now it’s time to back it up.
An evolutionary architect makes sure that your architecture can evolve, if needs be. On top of that, your architecture needs to be perfectly and easily integrated. In short: each component of the architecture should be able to evolve with time, independently of its environment in which it’s integrated.
How does an evolutionary architect differ from enterprise architect?
Before we can make clear how the plethora of architects differ from each other, we first need to find out how they are shaped within a business.
The enterprise determines the scope
What is usually done first to enable your architectural embodiment is determining the scope wherein you’ll be operating. This doesn’t necessarily mean that this covers the whole business of your client — it can be rounded off at just a small part of it, let’s say: a departement, a sub-division or a mini-company … you name it. This is your scope, this is your enterprise.
There are numerous types of architectures whose naming schemes are being used intermittently. There are your software architects, your lead architects, your technical architects — you name it. Whichever sounds the most appropriate to put on someones LinkedIn page on that particular moment in time. Whatever the scope, there will be a word for it. Moreover, your title will always be dependent on the project.
In short, we start with defining the scope of your architecture, which we call “the enterprise”. Then we’ll define the different components and how they are integrated within the enterprise. Thereafter we can find out what the roles of the lead architects are in the different components that make up the enterprise.
Defining your role
What’s up next is finding out what your particular role is within the scope / enterprise. Your role is dependant on the applicability of your architecture. In our case, an enterprise is not always synonymous to IT. An enterprise can entail almost anything. Business architects will check how your business processes are elapsing. If you take this into account, it’s not hard to imagine that business architects are not always necessarily IT folk.
For example: the mail responsible
Let’s say that every Monday morning there is a mail delivery at our offices. One person, the mail responsible, goes down to fetch a pile of envelopes and is responsible for delivering the mail at the right desks. This is a clearly defined business proces that can be mapped accordingly and integrated into other business processes thereafter.
Another person, the mail architect, can enforce a rule for the mail responsible to have some sort note-taking system in place — just like cleaning people mark down the time they cleaned a toilet. This is data. This data can be digitalised and thereafter be used by the data architects to take a look.
It’s possible that the enterprise architect decides there is a need for software to be created to make the delivery of the mail even more efficient. Then there could be a software architect that has its own scope within the enterprise.
Are you still with us? 🙂
So what does the enterprise architect do? They check their scope and try to interleave all the processes within his scope to make sure the enterprise improves. He starts from a strategic point of view of his own enterprise. And he makes sure all the individual strategic visions of the many different architectures are unified into one entirety. With a unified strategy in place, there can be a smart integration of all different components and ultimately a fast moving enterprise.
Strategy is defined by the enterprise architect
As we’ve already seen in our mail responsible example, there can be a multiple architects involved in one particular project. Everybody has their own ‘niche’.
- The mail architect that makes sure the most optimal procedure is in place to get the mail to the right person.
- The data architect makes sure the right data is digitalised and analysed (according to the strategic vision within their scope).
- The application architect that follows up on the software architecture, its integration and the strategy.
- The enterprise architect that defines the strategy of the entire business project.
The enterprise architect will make decisions on the strategic level. They will be guided by advice from the other architects that operate within his scope.
Application of the strategy is defined by the technical architect
On the other side of the strategic spectrum is the application of the defined strategies. The technical architect in most cases is also the IT architect and defines the system’s architecture
- Which printers will be used?
- How will people at home connect with my application?
- What is the look and feel of my application?
- how will the application be integrated with other applications?
- …
He’ll also have some strategic visions for the future, of course. But these are mostly from a technological point of view.
For example:
- How will the cloud evolve?’
- How will technologies evolve?
As you can see, these are mostly applied (long term) strategies.
Contrary to the enterprise architect (whose job it is to unify all the strategies of the different architects within the enterprise) the technical architect (and its hierarchical counterparts) is responsible for his/her own niche.
The enterprise architect will consider all things technical when he’s defining the global strategy for the business because it’s his job to unify the strategic visions of all different architects.
In conclusion: make the components evolve independently of each other to make it evolutionary
Making your architecture evolutionary means that whatever the scope is, an evolutionary architect makes sure that each individual component can evolve with the times and that it remains the ability to be integrated with other components within the application.
