Translate

November 25, 2014

The reason why IT architects fail, almost consistently, is modeling.

Summary: Because every architect will try to fit her solution in her specific model, the way architectures are created within a project is independent from each other. Thus within a project the application architecture is not really considered when creating the infrastructure architecture, nor is the data architecture or the security architecture. Consequently, creating an architecture for any business application is a waste of time. Or is it?

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:

  1. The project will not deliver on time
  2. 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,

Iwan

November 21, 2014

The not so disruptive nature of the cloud - Centralized vs. Democratized

So, as the title of this post suggests, I want to discuss the disruptive nature of the Cloud, or rather the cloud not being so disruptive at all. This will be a series of 5 posts in total, you're reading the fourth post.

Read about the cloud and what it means and you're bound to read that the introduction of the Cloud, the real Cloud, the one that meets all criteria for being a Cloud, has been disruptive.

I like the NIST definition of Cloud, it is quite comprehensive and less vendor-biased than Gartner's defintion.

The Cloud has been disruptive when it comes to the IT industry, especially the hosting market. But it has also been a force in how we handle IT within the enterprise. There are a few important aspects of IT in the enterprise that we consider to have changed due to the Cloud:


  • Moving from in-house IT management services to off-site IT management services. 
  • Moving from CAPEX (Capital Expenses) based IT investments to OPEX (Operating Expenses). 
  • Moving from on-premise (business) applications to off-premise (hosted) applications. 
  • Moving from a centralized IT to a democratized IT 

  • I'm sure you can think of other movements as well in your IT environment, but these are typically considered to be not only happening, but also to be disruptive within the enterprise.
    These are in fact not really changes happening due to the Cloud, the Cloud merely gave these movements a boost and fast-tracked the changes in IT.

    Last time, which was a while ago, I wrote about the location of the data center, or rather about where the IT Infrastructure was located. This time around I want to discuss how IT resources find their way to the user, the customer.

    Ever since the beginning of (business) usage of IT within the enterprise there has been a movement from either centralized governance towards decentralized or even democratized and back. But first let me explain what I mean by 'democratized'. It is actually quite simple. Democratized means that everybody and their mother can obtain or have access to IT resources in this case. Consider computers, storage, network access and software applications.
    In the era of mainframes, IT was centralized, with the advent of PC's it got democratized, with client/server architectures it moved back to centralized and with the advent of thin clients, it became even more centralized. But the key here is that we've been at a democratized IT situation a long time ago, when PC's were introduced and software was installed locally on the PC by either a support engineer or the user herself. As long as you could get hold of the installation disks (and of course a valid license) you could install whatever you wanted. This was very beneficiary for the agility of the user but very bad for cost control on IT support expenditure. Because with all that software installed, viruses got installed as well, rendering the PC's unusable and a support engineer had to come over and fix the problem.
    Another important problem with a decentralized and especially a democratized situation with respect to the IT environment is collaboration between users. Apart from the fact that there is in principle no common ground for data, or information exchange if you will, but the diversity of applications in use, similar applications at that, means that exchanging information, actually collaborating is cumbersome to say the least. This resulted in a move towards centralization where PC's are not much more than computers that allow for a user friendly interface on top of a centralized application.

    With the advent of the cloud, and specifically SaaS offerings, the model became intrinsically more centralized, but at the same time, because of the public nature of SaaS offerings, they also became available for anybody with a means to pay for the service, thus democratization entered the enterprise again. With IaaS, but more over with PaaS, the democratization of IT resources extended to not just (business) applications but also towards computing resources and storage. Both Amazon and Microsoft have a ton of additional services on top of their own platforms, provided by both themselves and third parties.
    Everybody with a credit card can get their own enterprise software running in the cloud, create their own development environments or deploy a new marketing website. Typically with better availability promises than their internal IT departments can offer.

    Is this a new way of working, is democratization a new way for enterprises to handle IT? Hardly. So once again, there's nothing disruptive here that is related to the cloud.

    So, why is the cloud really taking off? Why hasn't the hype died yet? Why is the cloud causing IT departments such headaches? In the next, fifth and last installment of this series, I will reveal the true disruptive nature of the cloud. Stay tuned.