Thoughts on Governance...

By special request of a fellow blogger I am posting the following opinions on governance.

Governance as defined implies a subset of people with authority, providing direction, and by default assumes some spectrum of politicking –- or more properly stated: differing viewpoints on shared issues. We will see governance in several domains, some formal some informal. We find governance in IT Strategy, Finance, Business, Projects, and even HR. Some of the more common formalized governance is very process-oriented. The informal governance of a decision can be handled with behavioral interaction (i.e. having unmanaged meetings with key stakeholders to gain consensus) peers and managers I have worked with often call this “socializing”. There is a subtle and more subversive means of informal governance in which influential individuals lobby for or against a decision / project / promotion. Although actions like this may historically have saved groups from serious mistakes, it’s not always repeatable and may create an environment where permission isn’t asked for...forgiveness is.

Although I enjoy articles such as this from ZapThink, I suspect there is no self-help audio tape, book, or analyst framework that has the secret-code on governance cracked (although by way of this blog I invite comments to the contrary!). It’s often a product of the culture. It can be a predictor of change. It’s usually a sign of delegated leadership. The one thing that I suspect most would agree on is that it’s always painful at first to get assimilated.

To conclude this soap-box, here’s my advice:

• Keep the process simple and well documented
• Keep the number of participants to the smallest number possible...but no smaller
• Invite resources from multiple parts of the organization to sit-in on sessions to eliminate shrouds of secrecy
• Identify neutral moderators who can set calendars and take notes
• Assess behavior aspects from two different dimensions:
(1) The organizational model...where you’ve been
(2) The strategy...where you’re going.
• IT governance needs to include people that understand the technology
• Governance can be more valuable across domains, too much detail will corrupt agility
• Governance decisions need to be audited and enforced
• If a leader appoints a governance body, that leader should avoid overriding or circumventing that body's delegated authority
• Success can be measured equally in work that gets halted as in work that gets accelerated
• Some of the best governance is self-governance and empowerment. Start with architect education. Groups of business analysts, project managers, developers, controllers, architects, application owners... all are candidates for taking on this accountability. By having everyone own a piece, a common respect and buy-in for the overall direction evolves.

In the end it’s just about leadership and prosperity.

BRE vs. BPM

The debate between BPM/Workflow engines and business rules engines (BRE) needs to STOP!!! Although there technically "CAN" be some overlap in an implementation, there "SHOULD NOT" be or customers may suffer refactoring and conversion when they finally define where lines are drawn. Oh yes, and let's not forget the analytics nightmare that can evolve out of this mistake.


Here's the answer...its really simple...okay...ready...everyone listening?

BPM tools are made for process automation, workflow and routing.

BRE's are made for decision management, can use inferencing, and are context sensitive.


Any attempt to select one to do the other is unwise. Period.
There are use cases where the two may be implemented in a complimentary fashion, but I will save that for a future posting.

I welcome comments on this or any post.

On Architects and Project Managers...

As our IT environment has grown more distributed, so hasn't the need to fragment the support of the assets grown? It used to be a business customer negotiated with an application manager (with vested interest in an application) to get work done. Nowadays a project may get assigned a PM that is not familiar with an application or the technologies in use. This is indeed a failure of the PMO mentality. James McGovern makes an interesting argument about PMs ... and other bloggers allude to a link between the technical background of a PM and their ability to be successful. PMs often get assigned to projects where a new solution or significant system changes is occurring. It is not their job to deliver on the promise of SOA or balance the impact of the changes to the IT portfolio--nor are they rewarded for such. That's the architect's role. There is goodness in a healthy tension between an architect and a PM on a project. Done correctly there is balance like Ying and Yang. Their priorities are just different. PMs need to get the function deliverables complete, on-time, with minimum number of resources and come under budget. Architects concern themselves with non-functional qualities, least amount of design change to meet the need, and implications to the greater environment. PMs need to be selected for their capability to deliver...the same reason you would not assign a DBA to write java code (no offense to those with both talents), you would not take a business-oriented PM ... and put them on an SOA refactoring project. Bottom-line it’s the right person for the right job. I know PMs that think like architects and I know architects that work like PMs. That's what makes them special.

Who is James Allan Tarbell?

James aka "JT" is an architect with a Fortune 100 Financial Services company in the Northeast.

Although he enjoys working in general solution architect he is also a Licensed Property and Casualty Agent with specialized experience in: Commercial Underwriting, CRM, QA/Test Strategy, Java Development, Web Development, Data Warehousing and Reporting, Middleware, Legacy Integration, Web Services, Portal, Performance Architecture, and Business Rules...to name a few.

In his spare time he enjoys reading about and discussing technology topics, doing home construction projects, and spending time with his wonderful wife, 4 yr old son, and 2 yr old daughter.

Please learn more about JT on his blog!

Warriors rule, Warhawks drool !

I see a fellow architect also named James is pleased I have joined the "blogosphere".

Hmm..."blogosphere", odd word ... why not "bloggernet"? ... the domain is available.

Anyway, looking forward to posting on several topics.
Thanks to James for inspiring me to start.
We can definitely agree that he and I will share some healthy debate and entertain our avid readers.

Architect Education Cleverly Disguised

Given proper instruction and reinforcement, the majority of architects can perform at an exceptional level.

We must develop our architecture skills and competencies leveraging the depth of our experiences and breadth of our perspectives.

Here's how:
Foster architecture leadership and become an agent for change.
Teach other architects how to apply and transfer knowledge.
Encourage creativity and innovation.
Learn to recognize mature thought.
Enhance your speaking and documentation skills.
Provide other architects with technical and business information.

Knowledge Crisis

When it comes to knowledge we all seek it, have been taught some, and yet have learned best on our own. I often feel that we are all wandering in the midst of a knowledge crisis.

Join me in this ongoing dialogue as we explore the knowledge crisis of an architect and try to make that which is tacit...explicit.