Taking a break

Taking a break

As I'm transitioning between roles, I had some time to reflect on the journey to here. What has gone well and areas for improvement. 

I had the opportunity to work for half a dozen electric utilities over  the last 3 years. I can finally answer the question, how do other utilities do X. The ironic thing is the answers to the meaningful questions are still it depends. Thew difference now is that I can quote examples. 

I underestimate the power of relationships. For most of my career, I have focused on delivery quality and continuous learning. One of my key take away from consulting is that I have improved the lives of others though work and my life has been improved by a large cast of characters. This network of support is stronger than contracts and its stronger than technologies.

Finally, much of what I've done over the last two years has required significant technical writing. I'm a little disappointed in the state of automation for architecture documents. I remember Rational SoDA and feverishly developing and updating templates. It looks like SoDA and even its successor Rational Publishing Engine have been discontinued. With Microsoft migrating to XML for Office formats, document automation should be even easier. Who does this well? What kind of work flows are other architects using for document automation? Anything in the OpenSource community or is this primarily a commercial problem?

Finally, I would like to do more blogging about technology and architecture. So hopefully more articles to come.

In search of ArchOps

ArchOps

Managing an Enterprise Architecture team and in a company that is moving through the DevOps transition, I was curious about what DevOps and Agile mean for application and technical architectures.

The simplest description I can provide for ArchOps is extending the merger of development and operations to include architecture and design that makes up DevOps to include Architecture. In doing so shouldn't we apply the same principles? The CALMS framework teaches us culture, automation, lean, measurement and sharing are critical to the transition to DevOps state. What happens when we apply these same principles to architecture practices and processes?

Culture

This is perhaps the most difficult aspect any transformation. What we do is more of who we are than what we say. In other words, wetware is notoriously hard to reprogram. Architects have a history of closed communities and carefully kept secrets. Its frequently referred to as ivory tower syndrome. This is really a symptom of some other behaviors. I know many systems architects and while they tend to be quirky, they know by not communicating well, they undermine their mission. The bigger issue is our analytical tendencies. Passionate architects want to take the problem off-line, mull it over, compare options, elaborate and repeat. When we have the most perfect idea then, we share. As architects, we need to understand how to better engage with the teams we serve and architect solutions iteratively and collaboratively.

Automation

Automation is the cornerstone of performance. Humans are craftsmen at the end of the day. Every time we do something we get a little better at it, but we also do it a bit differently. In creative endeavors this variation is good. In systems delivery variation is bad. A stable output requires consistent delivery. Automation in system engineering is hard. In many ways, it's like repairing an engine while the engine is evolving. Frequently architects don't fully describe a system, leaving the details to the domain experts which can also lead to unnecessary variation. I hypothesize that, through open standards and open tools, create an intersection of automated patterns and rigorous architecture that increases the pace of delivery, yet maintains effective governance.

Lean

Lean is another concept that is heavily rooted in culture. Lean isn't just removing waste from the process but it's instituting a habit of continual improvement. The Open Group Architecture Framework, TOGAF, is the de facto standard for enterprise architecture. However, TOGAF is a large framework that is designed to address all architecture needs. The TOGAF standard suggests that architects tune the process for the situation at hand. Lean can provide the type of guidance needed to streamline TOGAF for real-world situations.  

Measurement

Measurement is one of the taboos of the architecture practice. We talk about squishy measures like risk avoided/avoided cost, which no one ever believes, or percent of strategic projects that no one ever believes. We may also talk about designed components, configuration items, that no one understands or standards that no one wants. While I'm being a little overdramatic here, measuring the intangible is difficult. However, if there was an efficient way to connect the dots perhaps architecture measurement can be improved too.

Sharing

Creating a culture of sharing should be simple. Children are taught to share from their earliest childhood. Engineering is primarily a risk mitigation activity. Sharing too early can lead a project or a whole organization in the wrong direction. Agile approaches acknowledge the need to constantly reassess, but many organizations don’t have enough architects and engineers to constantly reassess these decisions. To facilitate sharing many organizations develop communities of practice or centers of excellence. Transparency is critical for sharing. Whatever is happening in the architecture team should be immediately visible and preferably executable to the rest of the organization.

Conclusion

I'm looking for a better way and I'd like to use this blog and the support of my community to find it.