So I have been fortunate to read Chess and the Art of Enterprise Architecture book by Gerben Wierda which has a lot of great material that opened my eyes to a much broader view beyond whatever I know so far. Wierda has a very long experience which meshing up everything that relates to technology and the advancement of the digital era. I will take his word for many things in the book as it is a more pragmatic and reasonable approach on how to establish an EA practice in an organization. Plus, his culture touches the northern parts of Europe which I, anecdotally, consider a very mature environment in understanding the enterprise architecture practices, along with Australia.
So there are many points that I agree with, like relying on frameworks and the practice of adoptions vs. adaptation. I personally and in multi-occasions expressed my open hatred toward TOGAF standard; not due to its maturity or practicality (who am I to judge), but rather due to the industry looking for TOGAF as the de-facto standard for EA. Well, that is for another talk.
The way he addresses that backcasting doesn’t work for today’s world and we need to re-think EA as mostly a shared responsibility of the enterprise health in the permanent changes by strategies, or in-flight initiatives is sensible and reasonable. We should think about an end game while maintaining the tactical moves as the full strategy is not realized until we reached to that future, and even then we will continue on another prospect through the same tactics. This approach solved an issue that I used to face it whenever I got bombarded by business change with my previous employer. Well, you have a roadmap, then good luck as it will change within less than one year!
Nevertheless, the book left some bad tastes on my mouth on some points pointed by Wierda. Maybe, this is because the book is relatively old (I know it is released a couple years back, but the landscape is moving fast). So here are these points along with my comments on them.
Positioning Enterprise Architecture within the confinement of IT
The engagement model presented by Wierda is a lightweight model that holds accountability, not responsibility, of the enterprise architecture health. It will review and approve initiatives by projects sponsors once the initiative is greenlighted and the EA spokesman report to the CIO. EA in this context acts as a reactive element that responds to the enterprise change, but in recent years the role of an enterprise architect is moved to a more demanding position next to the strategy office. It was made this way to let the EA unit acts in a more agile approach to respond to environmental changes. The strategy office place the strategic themes like objectives and start to communicate with business units to introduce changes (not to be confused with in-flight changes), and once the charters are ready the EA will see what business architecture elements must change in accordance. Things like business capabilities and value streams must be modified to accommodate enterprise change. That is where the EA shines with its holistic view of the enterprise as a living organism rather than a stateless entity. And with the total linking of the business elements to the IT infrastructure, the EA can facilitate reusability and minimize risks within a short time (I placed a reminder to elaborate on this in a different post ).
OK, this one got on my nerve like nothing else. OK, I understand the enterprise architecture principles are seldom considered like the “Buy before you Build” principle. But those principles are taken out of context. It is due to the existing of the EA office under the CIO that will consider principles that are only related to Information Technology things. Enterprise principles reside at a much higher level than that. It is not called “Enterprise” for nothing. When Zachman first defined Enterprise Architecture, he included everything that runs within the enterprise as a building block of the complete ontology and classification of the enterprise (the viewpoints, prospects, and intersections). He didn’t limit it to only the information technology. So, why would you include the principles as something guiding the work of a team under the CIO? I will elevate the principles into a higher dimension, at more business and strategic levels rather than the EA level. Svyatoslav Kotusev, who took his Ph.D. in EA, has placed the principles as a crucial element at the business dimension of his Enterprise Architecture on a Page model after studying many organizations. So, in my own opinion, I will consider the enterprise principles, with business values, as a necessary artifact to keep at disposal.
There is a business in the Enterprise Architecture!
Ok, this is much related to the first point I mentioned. But I can’t emphasize enough that Enterprise covers everything. As argued by Tom Graves, whom I have the utmost respect in this domain, in multiple instances that enterprise architecture is not just the IT alone, but the broader line of the existing of the organization along with what eventually makes it in the definition of the enterprise (like the clients, competitors, and regulators). So, IT is only just one aspect or viewpoint of the enterprise state and behavior. Nevertheless, In his book, Wierda gave the impression that the enterprise health is only constituted in the IT and anything that touches the IT which is in border light contradicts with the interworkings of the enterprise. So a change in the information map must be captured, analyzed, and communicated by the EA unit to ensure the total transparency of opportunities and risk across the enterprise.
The last chapter was hectic in design
Ok, the Project Start Architecture template chapter was genuinely confusing. I know the usage for such knowledge and document but couldn’t comprehend the overall organization of such a template as the responsibilities were vague to me.
Overall, the book is a great asset for my future references, and I recommend it to anyone interested in the domain as long as the reader has good insight on the subject.