Saturday, March 03, 2007
Should Enterprise Architects keep things at a high level?
If you are into useless truths then you are probably a person who likes to keep things at a high level...
Many enterprise architects are afraid of details as it may expose their weaknesses. We tend to prefer higher level information from industry analysts that summarize everything we need to know into a few crisp pages. Wouldn't it be interesting if universities could adopt this philosophy. Imagine getting your PhD by simply reading a few bullet points.
Keeping things at a high level are good in situations where buy-in is required and the recipient of the information isn't technical but can be taken too far is communication is targeted at other technical members. High level abstractions such as use-cases are wonderful and help guide software development. Likewise, avoiding detail in early stages helps avoid big design upfront and waterfall oriented approaches so pervasively implemented within enterprises.
Anyway, when enterprise architects keep things at a high level, there are at some level lying to their business community. High level communications are attractive because borrowing someone else's abstraction saves time and energy in the short haul while potentially jeopardizing success in the long haul.
Higher level abstractions are in some situations evil. Abstractions should be just an afterthought, create them and use them exactly when you need them, do not create them because you think you are going to need them. It is a waste of time to create abstractions before you can create the concrete examples, because you can't test the abstractions, you will get them wrong and you will have no way of testing them. NOTE: Many enterprise architects do this via Powerpoint and comprehensive documentation.
| | View blog reactionsMany enterprise architects are afraid of details as it may expose their weaknesses. We tend to prefer higher level information from industry analysts that summarize everything we need to know into a few crisp pages. Wouldn't it be interesting if universities could adopt this philosophy. Imagine getting your PhD by simply reading a few bullet points.
Keeping things at a high level are good in situations where buy-in is required and the recipient of the information isn't technical but can be taken too far is communication is targeted at other technical members. High level abstractions such as use-cases are wonderful and help guide software development. Likewise, avoiding detail in early stages helps avoid big design upfront and waterfall oriented approaches so pervasively implemented within enterprises.
Anyway, when enterprise architects keep things at a high level, there are at some level lying to their business community. High level communications are attractive because borrowing someone else's abstraction saves time and energy in the short haul while potentially jeopardizing success in the long haul.
Higher level abstractions are in some situations evil. Abstractions should be just an afterthought, create them and use them exactly when you need them, do not create them because you think you are going to need them. It is a waste of time to create abstractions before you can create the concrete examples, because you can't test the abstractions, you will get them wrong and you will have no way of testing them. NOTE: Many enterprise architects do this via Powerpoint and comprehensive documentation.
