Wednesday, January 05, 2011
Enterprise Architecture: Amorphous Blob of Human Insensitivity
A system, a diagram, a document or other artifact with no conceptual integrity often becomes an amorphous blob of human insensitivity. This also happens when an artifact grows rapidly with no refactoring. Some times too much ill-conceived or bad refactoring can turn a previously decent idea into an amorphous blob. It is sometimes facilitated by managers that use engineers as little more than interchangable parts. As a result, the software, its documentation or concepts at large has no more continuity or definition than the team has itself...
The Borgification of IT seems to occur in companies whose management team seems to recognize no shades of gray in talent or experience for non-managers and non-team leads. I'd like to think that even more than shades of gray in engineering, that there is a vertical career path that could parallel management without having to go through management. Something like an architectural path leading to Chief Architect or some such. Maybe making a move into R&D, shaping the technological agenda or making more strategic road map decision on product-line.
The Borg mindset of utter consistency almost always results in human insensitivity. Whenever artifacts include everything that recklessly has everything but the kitchen sink in it, even when it doesn't, you end up creating one. One of the more sinister practices in the creation of guides that are supposed to guide practitioners to a solution. Has anyone ever wondered why there are so many guides in problem domains such as data and security yet enterprise security and data quality in measurable terms are on the decline?
Visit the Microsoft Developer Network site (MSDN) and observe how they describe the problem domain of authentication and authorization. Did you note that the resulting API libraries are well-documented but otherwise are particularly insensitive to any conceivable user? Did you notice how problem domains where documentation are the focus are exacerbated when trying to use them from .NET, Ruby on Rails or some other modern language?
Has staff turnover, aggressive schedules and the desire for scripted changes aided in keeping things simple or simply resulted in a blob of human insensitivity? Despite what we hear, all engineers are not interchangeable. Two people can be in the industry for the same length of time and have widely different ranges or depths of experience. Is it a best practice to ignore the unique experiences of members of the team and instead strive for human insensitive homogenization?
Let's pretend for a moment that you are a project manager within an large enterprise setting and you work for a boss that refuses to allow you to do one thing really well and instead prefers to give you multiple assignments. You face the challenge of managing two projects, both of such a high priority that you cannot assign an engineer to one of them and ignore the other. You somehow think that you are brilliant in assigning the engineer 50% to one project and 50% to the other and declare that this makes excellent use of the engineer's time. People can easily devote exactly four hours of thought per day to one project, and four hours to the other. And if there are three high-priority projects, assign the engineer 50% to project A, 50% to project B, and 50% to project C.
A real engineer will eschew such sage wisdom human insensitivity and will normally work one of the projects and ignore the other. Parallel task lines on a schedule look nice and they save you, as a manager, effort in explaining why something has not started yet, but parallelism does not get the tasks completed any sooner. Serialization is the most efficient use of resources to get the projects completed in the least amount of time. Being full time on a project is almost always better than being split - unless you're stuck or waiting on somebody else. When you're full time then the project gets your "shower thoughts". By working one to completion and then the other you finish on average ahead of when you would have with a parallel approach.
| | View blog reactionsThe Borgification of IT seems to occur in companies whose management team seems to recognize no shades of gray in talent or experience for non-managers and non-team leads. I'd like to think that even more than shades of gray in engineering, that there is a vertical career path that could parallel management without having to go through management. Something like an architectural path leading to Chief Architect or some such. Maybe making a move into R&D, shaping the technological agenda or making more strategic road map decision on product-line.
The Borg mindset of utter consistency almost always results in human insensitivity. Whenever artifacts include everything that recklessly has everything but the kitchen sink in it, even when it doesn't, you end up creating one. One of the more sinister practices in the creation of guides that are supposed to guide practitioners to a solution. Has anyone ever wondered why there are so many guides in problem domains such as data and security yet enterprise security and data quality in measurable terms are on the decline?
Visit the Microsoft Developer Network site (MSDN) and observe how they describe the problem domain of authentication and authorization. Did you note that the resulting API libraries are well-documented but otherwise are particularly insensitive to any conceivable user? Did you notice how problem domains where documentation are the focus are exacerbated when trying to use them from .NET, Ruby on Rails or some other modern language?
Has staff turnover, aggressive schedules and the desire for scripted changes aided in keeping things simple or simply resulted in a blob of human insensitivity? Despite what we hear, all engineers are not interchangeable. Two people can be in the industry for the same length of time and have widely different ranges or depths of experience. Is it a best practice to ignore the unique experiences of members of the team and instead strive for human insensitive homogenization?
Let's pretend for a moment that you are a project manager within an large enterprise setting and you work for a boss that refuses to allow you to do one thing really well and instead prefers to give you multiple assignments. You face the challenge of managing two projects, both of such a high priority that you cannot assign an engineer to one of them and ignore the other. You somehow think that you are brilliant in assigning the engineer 50% to one project and 50% to the other and declare that this makes excellent use of the engineer's time. People can easily devote exactly four hours of thought per day to one project, and four hours to the other. And if there are three high-priority projects, assign the engineer 50% to project A, 50% to project B, and 50% to project C.
A real engineer will eschew such sage wisdom human insensitivity and will normally work one of the projects and ignore the other. Parallel task lines on a schedule look nice and they save you, as a manager, effort in explaining why something has not started yet, but parallelism does not get the tasks completed any sooner. Serialization is the most efficient use of resources to get the projects completed in the least amount of time. Being full time on a project is almost always better than being split - unless you're stuck or waiting on somebody else. When you're full time then the project gets your "shower thoughts". By working one to completion and then the other you finish on average ahead of when you would have with a parallel approach.
