Recently, I was reading a 2-part article series by Eoin Woods on software architecture woos and worries, though he terms as mistakes. Part 1 addresses top-5 and Part 2 addresses the rest. He mostly shares his own experience as a software architect for years.
Buckle up, never do these mistakes – It’s The Law in the Enterprise Architecture world.
(1) Scoping Woes
(2) Not Casting Your Net Widely
(3) Just Focusing on Functions
(4) Box and Line Descriptions
(5) Forgetting That It Needs to be Built
(6) Lack of Platform Precision
(7) Making Performance and Scalability Assumptions
(8) DIY Security
(9) No Disaster Recovery
(10) No Backout Plan
There are many more amendments to this law. It comes by practice, not just by experience. This reminds me of Ted’s post on the great expectations of a software architect. The relevance in architecture is severely dictated by a team of influenced personnel who has the authority to approve or decline recommendations by architects or technologists. Architects need to understand the business relevance and technical relevance. Not all projects have the luxury of having an architect who understand all these. I have seen technical leads performing this role many a times. A project may not really require an architect if it has well defined functional and non-functional requirements, skilled developers who understand the requirements, and to some extent domain knowledge. This is not a perfect world where you get all these concrete before you start a project. Exceptions are there, but not the majority. Remember, having an architect, its no silver bullet. I need to stop here as my thoughts are deviating from the original intent of this post. But, I would like to revisit this topic in near future.
Blogging at the speed of thought 