Probably, when you're like me an architect or like some people I know a project manager, you already know that involving an architect in your project, or acting as an architect in a project guarantees exactly two things:
- The project will not deliver on time
- The project will not stay within budget
Of course I'm just kidding, in fact you should be experiencing the exact opposite, involving an architect in your project or acting as an architect on a project, provided the architect is considered to be a project member and not somebody that can get a project out of a dire situation, means that the project is most likely delivered on time or as close as possible to it and all within budget or close to the budget. This is what the architect does and there's more. The architect will ensure that the deliverable will be of a higher quality and therefore be of more use once taken into production. The promised or predicted ROI (Return of Investment) from the business case is more realistic.
The reason why the architect is helping with this is not because she's architecting the deliverable, although she is, that doesn't really help. The reason is that the architect is the single one person in the project that is looking at the problem(s) at hand from a holistic point of view. Approaching from different angles and addressing issues with an open mind. Architects have the talent to think outside of the box, creativity is their key capability.
Still, architects almost all fail all the time in doing architecture, that is IT architects. Because this blog is about IT architects. The key reason here is that they are architecting within the boundaries of their area of expertise.
So what do I mean by all this. It's actually quite simple. Consider yourself in case you're an architect or that person in your project that is the architect. What kind of architect is she? Most likely, we're dealing with an application architect, an infrastructure architect, a security architect, a data architect, a UI architect, an information architect, a business architect or maybe even an enterprise architect. Point here is that within pretty much any serious business application, you're touching all of the areas discussed above. But hardly ever do you see an architecture that is integrating all of these areas into one single model.
Architects are working a model and in the best of cases, are handing their model to other architects to make them aware. The project manager has no clue of what's going on or dares to make any assumptions as to what is going on here. But the case in point is that the application architect creates the application's architecture, hopefully taking the input from the business architect to understand where in the various business processes the application is being used.
Once the application architecture is done, the security architect is tasked to make it secure. This is when the application architect is not suffering from a god complex and doing all that security design afterwards himself. Obviously the data architect has no clue as to what is going on, because he's never involved. The application architect did all that work instead. Because, data is an integral part of the application, so...
This is where the architect is done and the project's developers take over. Best case scenario, the resulting application is close to what the architecture intended it to be. At least the application will adhere to some of the enterprise's standards, values and principles. Once all that development is over, the infrastructure architect is requested to, oh wait, best case scenario, the application architect is reviewing the application for compliance with the architecture, and this is when the infrastructure architect is to create the infrastructure architecture on which the application is deployed.
Okay almost the same scenario, but now the story starts with the infrastructure architecture and the application architecture is subjected to the infrastructure architecture.
Now do the same with a security architecture to start with and ...
In all these scenario's the different architectures are created as separate products. One is subjected to the other. There's really absolutely nothing holistic about it. There's nothing integral to it either. And it makes no sense when you think of it.
I will not make an analogy with architects of buildings or other physical structures because there is hardly an analogy.
The issue at hand here is, as I stated, that the different architectures are considered separate products, with hardly any coherence between them. For some weird and actually inconceivable reason, we're let to believe that a security architecture can be created separate from an application architecture and infrastructure architecture and data architecture and business architecture. This is of course complete nonsense. There is no way you can create a generic infrastructure architecture, not even a high level reference architecture without understanding the application that will have to run on it. Same for a data architecture. What's the point of having that without knowing the application of the data in a business process? There is none. Don't let anybody fool you, because it's just not there.
An important reason why we are working this way, is because we are let to believe that we need to work with models. Decent architects will at least not try to fit the world into their models, but every architect will work with models. Which makes sense because this allows them, us, to simplify the problem's solution. Understand the model and you understand why the solution works. But have you ever tried to come up with a model that covers all of the architectures mentioned before? A single model? Have you tried to draw a diagram that shows it all? And in case you tried, did you succeed? It's not possible because the perspectives, the points of view, the points of interest are different for each of the architectures. They operate, they concern themselves on different levels of abstractions and with different levels of detail.
Because all these models consist of different elements, different symbols is used on the diagrams and the level of abstraction is seemingly different, the architectures are done separately, in a logical order to the project manager, the enterprise's culture and the individual relationships between the architect. Key point is that the consistency between architectures is coincidental.
Hence, the creation of any architecture in the end is a waste of time, because none will hold when the project manager actually wants to deliver on time and within budget. Because he will sacrifice security over deadlines when it costs too much implementing the infrastructure according to the architecture. The data architecture is thrown out the window as soon as the application is not performing because of the database queries. Etc.
There is a solution to all this and that is to create a truly integrated and holistic architecture of the complete solution. Have all these architects work on a single architecture that encompasses all these different aspects and have a single solution architecture that addresses application composition, data structures, business processes, infrastructure and security consistently.
This requires that dogma is thrown out the window and reference architectures are basically just informed decisions on architecture principles and guidelines with architecture blueprints emanating from them.
But most importantly, it requires a model that covers every single aspect of an application. And I mean every single aspect. The model must and can only be a meta model. A definition of a business application defined in data elements and their inter-relationships (including cardinality, direction of traversion etc) that allows for the definition of every single aspect of any business application. This meta model is a data model.
And there's the key to the issue, the model we're having to deal with in order to make an architecture worth creating, is a data model. The different architectures we're used to having are just different views on that data model. This allows for various levels of abstraction with various level of detail, as however of interest to the reader.
Because the model is capable of capturing every aspect of the business application, the model is capable of capturing every aspect of a set of business applications, hence it allows us to capture the complete application landscape and hence consistency across the board, architecturally speaking that is.
Now why is this so important, what is the significance of having a single model for all architectures to be based on? The significance is in the fact that all of a sudden an architecture cannot be subjected to another architecture, because there is only one architecture. Consistency and coherence are a given, it is impossible to not have a concise architecture that is comprehensive and all encompassing because that would mean that part(s) of the architecture are not finished. Which is fine because it will have to be a conscious decision to omit these parts.
In addition, for application developers it will be counter-productive not to stay with the architecture, because that will mean that deployment in production will be harder, because every single aspect of the application is taken care of in the architecture. Thus allowing the developer to concentrate on quality, and consequently an improved ROI.
I hope you enjoyed this blog post, I for one want to thank you for reading it. I am aware that this post was quite long, but I hope worth your while reading it. Please leave any comments, agreements or disagreements as the more views there are, the better sight we all have,
Post a Comment
Note: Only a member of this blog may post a comment.