Management and Governance

Thanks to James McGovern, Brenda Michelson, and Sam Lowe for their comments on my last post on EA and SOA. Sam’s response, in particular, got my mind thinking a bit more. He stated:

One of contacts likes to describe EA’s new role in the Enterprise as being managing SOA-enabled (business) change.

The part that caught my attention was the word managing. What’s great about this is that it’s an active word. You can’t manage change by sitting in an ivory tower. Managing is about execution. EA’s not only need to define the future state using their framework of choice, but they need to put the actions in place to actually get there. Creating a powerpoint deck and communicating it to the organization is not execution, it’s communication. While communication is extremely important, it’s not going to yield execution. Execution involves planning. Ironically, this is something that I personally have struggled with, and I’m sure many other architects do, as well. I am a big picture thinker. The detail oriented nature of a good project manager is foreign to me. I’ve told many a manager that assigned me as a technical lead or a project architect to assign the most detail-oriented project manager to keep me in check. It may drive me nuts, but that’s what it takes to be successful.

Moving on, how does governance fit into the mix? First off, governance is not management, although the recent use of the term in SOA product marketing has certainly confused the situation. James McGovern has blogged frequently that governance is about encouraging desirable behavior. The book IT Governance by Peter Weill and Jeanne Ross states that

IT governance: Specifying the decision rights and accountability framework to encourage desirable behavior in the use of IT.

One of the five decisions associated with IT governance stated by the book is IT Architecture, the domain of the Enterprise Architect. I think the combination of decision making, strategy setting, and execution is what the EA needs to be concerned with. An EA group solely focused on decision making without having a strategy to guide them is taking a bottom up approach that may achieve consistency, but is unlikely to achieve business alignment. An EA group solely focused on strategy becomes an ivory tower that simply gets ignored. An EA group focused too much on execution may get mired in project architecture activities, losing both consistency and direction.

Added note: I just saw Tom Rose’s post discussing EA and SOA in response to my post and others. It’s a good read, and adds a lot to what I said in this post.

3 Responses to “Management and Governance”

  • I very much agree with above post.

    There exists a very thin line on which Enterprise Architect walks. Few responsibilities under his domain are 1) to assess current state and visualize future state (as is moving to to be state) of architecture, 2) Provide consultancy to Business Units, Architects & developers 3) champion Enterprise Architecture benefits 4) support Governance 5) develop strategies 6) to keep eye on emerging technologies. Taking too much interest in one area will impact the other area and results in loss of focus of Enterprise Architecture Group as a whole.

  • We like to think of “governance” as “the architecture of management”…

  • […] Todd Biske: Outside the Box SOA, BPM, and other strategic IT initiatives All information herein represents my own opinions, and not those of my employer or any other third party except where explicitly stated. « Management and Governance […]

Leave a Reply

Ads

Disclaimer
This blog represents my own personal views, and not those of my employer or any third party. Any use of the material in articles, whitepapers, blogs, etc. must be attributed to me alone without any reference to my employer. Use of my employers name is NOT authorized.