Monday, March 05, 2007
Do Enterprise Architects understand Engineering?
An IT executive whom I have the utmost respect for is always talking about engineering principles. Figured I would share publicly, what I believe he is referring to...
Before we get started, it is vital that folks don't get it twisted and confuse architecture with engineering. An architect may (and usually does) design something without regard for engineering. The deliverable may meet esthetic requirements but otherwise may not conform to sound engineering principles. Engineering contains the following notions that aren't never really discussed in context of architecture:
Enterprise Architects will probably struggle the most with the last bullet as we tend to be more believers in consensus building than in engineering principles. Consensus building tends to travel the path where the optimal solution is eschewed in favor of the more popular solution. Likewise, Enterprise Architects at large, still are controlled by the business instead of being viewed as an advocate.
I am of the belief that if Enterprise Architects start studying the discipline of engineering, we will make our enterprises better in the long term. Of course, there will be pain in the short haul as folks may not be ready for disciplined thinking, but the payoffs are too important to ignore...
| | View blog reactionsBefore we get started, it is vital that folks don't get it twisted and confuse architecture with engineering. An architect may (and usually does) design something without regard for engineering. The deliverable may meet esthetic requirements but otherwise may not conform to sound engineering principles. Engineering contains the following notions that aren't never really discussed in context of architecture:
- Testability: Software should be designed to have a repeatable test that can be performed to ensure that it is as expected. With bridge building, you could test the concerete, the steel, expansion and contraction in hot weather, etc.
- Maintainability: Software should be designed to last. A bridge should last twenty years with a designed way to maintain the bridge or safely widen the bridge if so desired.
- Integrity: Software should be designed to have structural integrity. A bridge will not just break in half. In memory state must not just become corrupt.
- Integration: Software should be designed to have a particular well defined way to integrate with its environment without any confusion. A bridge takes cars. There is a sign that says the maximum tonnage and height of the bridge; zero confusion. NOTE: This is not what SOA is really about, so don't get it twisted.
- Ethics: Engineers act primarily in the best interests of:
- the above principles
- the users
- the client
- Management: An engineer is proactively involved in the management of various responsibilities because the ultimate responsibility rests on the engineer. An engineer does not sit on the side listening to builders about bridge building. An engineer is actively involved in listening to builders and will let them do their speciality but is proactive in coordinating the various specialists towards the ultimate goal. Bridge building is typically managed by civil engineers - there are concrete and steel specialists but they are typically coordinated at a design level by the engineer, not by business.
Enterprise Architects will probably struggle the most with the last bullet as we tend to be more believers in consensus building than in engineering principles. Consensus building tends to travel the path where the optimal solution is eschewed in favor of the more popular solution. Likewise, Enterprise Architects at large, still are controlled by the business instead of being viewed as an advocate.
I am of the belief that if Enterprise Architects start studying the discipline of engineering, we will make our enterprises better in the long term. Of course, there will be pain in the short haul as folks may not be ready for disciplined thinking, but the payoffs are too important to ignore...