As I’ve argued in Chess and the Art of Enterprise Architecture, the high-level no-detail GOFEA enterprise architect is mostly useless in the fight to solve the pressing issues architecture needs to solve.
Not taking that ‘deep’ knowledge into account will lead you on paths that will fail in a spectacular way, burning money as you go. Creating a cloud-strategy, for instance, requires knowledge on low level details such as latency or some arcane rules from the regulators related to data protection, to mention something non-technical. These are not aspects you can delegate, it is an integral part of what it is to be an architect. There are two serious problems with the classic approach: you actually need a strategy focus too when handling deep technology and you do need to pay attention to relevant (technical) details to make a good strategy. It is, in that respect, a bit telling that enterprise architecture is often defined by its practitioners as what is it not (not solution architecture, not IT, not technical, etc.), much less what it is. The level of detail an Enterprise Architect goes into is usually limited, delegating the decisions to the specialists assigned to each particular area.” The whole setup is classic, and for me it always seems to stem a bit from the desire of enterprise architects to explain what makes them so special anyway, what makes them different. Concerns of Enterprise Architecture “are the lifecycles of the applications and what technologies are used by which one” and “ that the company as a whole have integrity and consistency.
Finally, “an Enterprise Architect’s main interest is describing the company in terms of its business entities, its properties and the relations between them and the external environment”. Not every project gets a Solution Architect, only when “the risks associated with technology are perceived as significant” or “when we are outsourcing development to an external team”. “Solution Architects ensure the technical integrity and the consistency of each solution at a certain stage of their lifecycle must have a very broad knowledge”. Recreated from an example by leanIX.Īccording to leanIX, “Technical Architects provide technical leadership for development teams” and examples are ‘Java Architect’ or ‘Infrastructure Architect’. The kinds of architects according to orthodox EA. I’ve recreated their picture which is pretty clear: But I thought this blog from leanIX actually presented the orthodox position well.
Commercial interests are an important part of innovation and skills. That is even true for groups that seem to be run by neutral associations (which sometimes are just another interesting form of commercial enterprise, but I digress).Īnyway, that doesn’t mean what is distributed is by definition nonsense, of course. The people maintaining the groups have to get paid, and as there are no paid subscribers, editorial work is paid by those that have something to sell.
Enterprise architect vs solutions architect free#
Which proves one more time that there is no free lunch. This even leads to the occasional censorship. Incidentally, there are several architecture groups on LinkedIn, and except The Enterprise Architecture Network -which is so unmodified that very off-topic posts end up there- they tend to be run by commercial interests and they tend to consist mainly of posts that are part of the marketing presence of companies in the enterprise architecture field. I’m prompted to write this because I recently came across a blog post announced in different architecture groups on LinkedIn. Implicitly, this says “enterprise architecture is about high level and strategy only.” There is something that I call “the orthodoxy” (or Good Old-Fashioned Enterprise Architecture-GOFEA see GOFAI), which says that enterprise architecture is about high level strategic issues, whereas-say-solution architects are more about details and technology. I generally rather talk about real architecture issues than about architects (navel-gazing is something enterprise architects are particularly prone to do and I like to stay away from it as much as I can), but there is something about the roles for architects you recognise that says something about the way you see architecture.
0 kommentar(er)
