Architecture – as I took 4 years of Greek it’s always meant the same word to me: that what stands at the beginning of construction, “ἀρχι-τέκτων”. Tekton is a builder / carpenter, and I was sure there was a verb tektein, but after looking for hours I’m afraid that this is it. At least arche doesn’t mean leader, it’s the Greek word for beginning – so don’t get fooled by online etymology sites or even wikipedia
Now, I’m not so sure. An architect used to be a sort of foreman overseeing and instructing the builders as well. Comparing that to IT, I think we’ve had almost 2 decades now of Architecture that were moderately successful.
Moderately, because initially a lot of people floated their way up into the architectural layer due to a lack of weight. Now we have various certifications, of which TOGAF is a reasonably good one, and quality has significantly increased – but there are other issues now
One of them is the decreased size of projects, and the increased distance between the Architect and the Workers – and you know what happens when the cat’s away.
We’ve effectively gone from constructing IT products that benefit the business, to merely delivering projects. Somewhere at the far end of the enterprise stands the Ivory Tower of Architecture that gets updated every 5 years at best, and at the front lines agile teams deliver projects at the speed of light.
The involvement of architects has decreased over the years, partly due to their relative high cost and small numbers. On the other side of space, developing code has become increasingly cheaper and pallets of dime-a-dozen programmers are wheeled into the enterprise
Usually, an ancient architect (foreman) would inspect the work every single day and witness the completion of construction. Typically, an IT architect now does what a modern construction architect does: draw a pretty picture of what should be, visit the site a few times in the beginning and maybe get invited for the festive opening of the building. That very last action usually misses out in IT
An architect stands at the beginning of construction, but over the years the focus has moved towards the end. Application life-cycle focuses on the total product, not just the projects that deliver them. Maintenance and governance have become increasingly important as that is where most of the cost is at: fixing errors or fulfilling user requests becomes a few factors costlier by every phase of a product
So, hence my suggestion: as the focus of cost has shifted from the beginning to the end of an IT product, let’s move the architect along with it. Or rather: the telotect.
As arche (αρχή) is the Greek word for beginning, telos (τέλος) is the word for end. So I propose for the new role of telotect, and maybe even a whole new field of telotecture: to cover the end phase of an IT product.
Telotectural principles must be directed at Governance, maintainability and cost-efficient time-to-market, and be directed at application re-use in the sense that an application moves from project-driven to product-driven, focusing on actual recent documentation, application (automated) test sets, version management and guard over an application registry: telotectural principles should guarantee a proper landing of applications in the IT-landscape and eliminate the need for application rationalisation efforts every few years
What’s your stand on this? Does Architecture suffice as-is, or do we need some form of telotecture? And could then architects cover that, or is it so very different that only telotects can?
(Cross-posted @ Business or Pleasure? - why not both)