Assessing organizational capabilities from a grassroots level

The classic big picture view of the organizational capabilities requires a certain vantage point from where the picture is drawn. It requires visibility into some of the esoteric areas within an organization. Quite often the big picture is either fuzzy or incomplete. On top of that there are solutions in progress that require a good understanding of the capabilities of the organization.

In my view, one way to work around such situations is by individual initiative and commitment. If the capability domains are known, try striking a conversation with the key players within those domains. You will be surprised at the quality of information that comes out. Sometimes these conversations help dispel some well-known myths and help establish certain lesser-known facts. This is also a good starting point to identify the missing pieces from the big picture. Conversation-chains help discover other key capability domains. Finally, cross referencing such information obtained from the different capability domains promotes a better understanding of what we seek.

Need an Architect to baby-sit my requirements

A common perception of an architect is that of an alpha geek, the go-to guy for all technical problems. Often architects do evolve from deep technical backgrounds, and do tend to carry that air around them. It is not surprising when that impression ends up fortifying the common perception.

Being stereotyped that way doesn't really help when you want to progress up the value chain. You get to hear things like, "We never thought you would be interested in the business side of things". It then becomes a tough uphill battle to get into the space where solutions to business problems are being crafted.

Can an Architect be an effective Project Manager as well?

When you look around in the job market, you see job postings that require both Architectural and Project Management expertise. Typically these postings are from companies that don't have an established architecture practice but that recognize the importance of architecture.

The question that comes to my mind is, 'Can an architect be an effective project manager as well?’ From what I understand, after having worked as an architect and after having dabbled with project management, the general attitude of the practitioners within these fields is very different. As an architect, you are trained to abstract complexity, and to only delve into details that are architecturally significant. As a project manager, you are required to delve into the lowest level of detail and to work out their dependencies.

Maybe there are projects of a certain scale where having an Architect/Project Manager works out to be more cost effective.

HP's Ecosystem and its bearing on Enterprise/Software Architecture

I was listening to a podcast by Businessweek that interviewed Sam Lucente, who is the Vice-President of Design at Hewlett Packard. He talked about the concept of universal design, also referred to as HP's Ecosystem.

In the conversation that ensued, he talked about 3 approaches. The first, Design to Simplify that allows to drive reusable design elements. The second, Design to Differentiate that relates to how to differentiate oneself in the marketplace. The last, Design to Innovate that helps create new markets and new business models. In terms of articulating contributions to the bottom line of the company, Design to Simplify had a direct impact whereas Design to Innovate was the most difficult to articulate.

In my view, these approaches are equally applicable to the realms of Enterprise/Software Architecture. Not only that, these approaches appear to be evolutionary, in the order as described above. For companies that are still exploring the value of having an architecture practice, the most attractive value proposition would be to use architecture as a means to create reusable elements.

The next steps in the evolution of an architecture practice would be where it helps a company to Differentiate and to Innovate.