Enterprise Architecture: Is commitment a worst practice?

There is one sure thing that will kill any project! That is the belief that you must give yourself utterly to it. It's the death of marriage, it is the death of any work environment. To say, I must deprive myself of other things while I give my attention only to you in a foolish practice within large enterprises...



In an enterprise setting, commitment comes in many forms. First, there are people who are committed to adhere to office hours, nothing more, nothing less. The flip-side of this is that without an insistence on standard office hours, there are many that would work far more than they should. If a conversation with human resources starts with the notions of a forty, fifty or whatever set hours a week, then the enterprise is doomed to mediocrity.

Agility isn't achieved by standardizing the number of hours worked but by focusing on achieving a sustainable pace. The McGovern principle of work/life balance starts with acknowledging that you can only work as hard as you rest



The whole problem is a result of bad management logic where the thought centers around the notion that a time-clock is an accurate measurement of payment for work done. It's resultant from either a manager that can not comprehend what developers do, or a manager that is too far detached from the daily work of the peons.

For the record, I am not advocating doing away with the timeclock. In fact, I believe there are certain cases where it could be leveraged. If a person can get their work done in three hours and can get time to slack off, they can pay back some of their decompression debt.

In the same way that refactoring pays down design debt, The more overtime you work, the more "decompression" you need in the form of vacations, short-hour weeks and "dead air" (time spent at work not doing anything useful -- or worse, doing actively stupid things). If you never need any decompression, you can continue indefinitely. Sometimes you need to steal some hours now (to finish a project) in exchange for extra decompression later.

The problem is that most projects and leaders managers rack up the debt and only make the minimum payment -- they try to do a bunch of little things to keep the overworked developer happy without solving the problem that made him unhappy to begin with. As a result, the developer begins to cost more and more to keep: bigger raises, more "personal days", more inactive time at work, negative effect on others and so on.

So, going forward you need to encourage commitments where it makes sense and likewise ask for commitments that don't violate other commitments...

Thoughts on Forrester Analyst Communities and Transparent Research

I currently participate in Forrester's various communities and like the interaction with many of its analysts. With that being said, I think there is much room for improvement....



So, here are a list of improvements I would suggest to make Forrester's communities much better...

1. All analysts should be encouraged to participate: In the communities I participate in, the majority of Forrester analysts are missing in action. Being community-oriented shouldn't be left optional nor thought of as something done in one's free time between billing clients. Forrester needs to make this activity a first class citizen and incorporate participation metrics as part of an analysts annual review cycle.

2. Communities should be more tightly linked to reserach: Have you ever noticed that the pretty much all of the analyst content is static and never changes after it is released? Wouldn't you think that if hindsight is 20/20 there would have been opportunities to update previously published research? More importantly, have you noticed that analysts aren't replying to comments left on their research and defending the research position vigorously?

3. Why are analyst firms immune to attribution?: The community brings with it insights that the analyst would not have came up with on their own. Why is it so difficult for analysts to acknowledge this insight in the opening of their research? Don't you think you are doing the community a disservice by not acknowledging their contributions?

4. End users have their own research agendas too: Wouldn't it be great if they were acknowledged, harvested and assigned? While it is noble for an analyst to propose their own research, shouldn't there be a mechanism that is fully transparent where one could propose and see the workflow behind the proposal?

5. Research shouldn't be the sole domain of analysts: Communities are more than capable of creating and publishing their own research. Why wouldn't Forrester want to become the destination for all community published research released under Creative Commons for example?

Thoughts on Cloud Security...

It would seem to me the focus on the security posture of cloud security providers is well, misfocused...

Let's face it, many cloud providers use the same underlying technologies as large enterprises. This may include various flavors of operating systems such as Linux to virtual machines such as Java or .NET. They will also be running some form of virtualization technology to provide the fundamental isolation from other tenants. So, shouldn't enterprise be worried less about the security posture of any individual cloud provider and instead focused on the security of software deployed regardless of whether you run in the cloud or not.

There are obvious practices an enterprise can leverage before deploying their application to public cloud ranging from the ability to encrypt all sensitive information, to even running your application across multiple cloud providers but security of the cloud still isn't guaranteed in that if the software stack used across all the providers is insecure, then you will still get compromised...