Enterprise Architecture: From Incite comes Insight...

A critical analysis of a blog entry by Mike Kavis is in order...



Mike asked the question: why do we hate process so much anyways? which the answer is simple. No one hates process, everyone hates bad processes.

I was working on small teams and sometimes I was simply the only one on the team. There was no established architecture and no standards. Since this was the norm and nobody cared, why bother me with tons of documentation.

Architecture always exist regardless of whether it was documented or even acknowledged. Likewise, I bet that while no standards where documented, you were alot more rigorous to the ones you held in your own head and didn't deviate creating standards that are defacto which isn't a bad thing.

As I moved through my career I worked on larger projects that spanned multiple user groups and application silos. Suddenly, the lack of process became a recipe for failure.

I wonder if it was a lack of process or a lack of either an architecture that worked across silos as well as no one who ensured conceptual integrity across them (aka Chief Architect)?

or those who don't like process, I can meet you half way. I believe in a lightweight process that supports agile development but not process that creates bureaucracy and results in 12-18 month projects that are doomed for failure.

Hybrid approaches are a sign of a mental disorder. If you allow everyone to heist their legs and add their own unique smell, then you will loose conceptual integrity and at best achieve mediocrity. You should encourage others to standard for principles over processes as well.

In addition we are working towards 12 week deliverables where we work on multiple workflows concurrently that need to plug in together at the end

I hope you realize that you made a massive mistake by having such long intervals. Have you ever heard of daily builds and the Agile Manifesto? 12 weeks is a very long time to get way off track.

The trick is to not create so much process that you stifle creativity and make technical decisions based on process instead of business need

You should measure process based on quantity but also result. Many enterprises rollout processes without figuring out their ROI and more importantly if it does achieve an ROI, they don't attempt to make it lighterweight over time to make the ROI even higher.

Outsourcing is a decision our company has made so my job is to make it work regardless of what I think about outsourcing. I can complain about it and allow us to fail or I can make it work.

Yes, it is the job of every employee to have the vested interests of their employer in mind and you should make it your duty to ensure that outsourcing works. The key thing though is that failure sometimes is also the right answer.

One of the most important tools is clear direction and good communication.

Agilists would consider communication as one of those people things and not through it into the tools category. In terms of tools though, I wonder if Mike Kavis is allowing his outsourcing firm to deliver insecure software or was he wise enough to ask them to write code securely by standards such as the OWASP Top Ten?