Service Provider Paradigm Shift for Enterprise Architecture Teams
I recently had the opportunity to share an idea with a group of enterprise-level Architects and received a healthy bit of positive feedback on the idea. So, I think its worthy to share more broadly.
Most, if not all, Enterprise Architects have witnessed challenges delivering a successful Enterprise Architecture Team. I certainly have observed failings and I’ve been involved in failures directly. My Enterprise Architecture team has tried something a bit different that seems to be working and I’d like to share it with you.
The basic premise is that traditional Enterprise Architecture teams tend to lean toward delivering things like:
- Conceptual Information Models
- ‘Stick’ Governance Models
- Principles and Standards
- Position Whitepapers
- Architecture Review Board Sessions
- Consultative-only advice
While all of these are nice to have, by themselves I believe they lead to the Ivory Tower. It’s no wonder why Enterprise Architecture teams that only do the above also tend to have the following challenges:
- Struggle to prove valuable
- Struggle to be influential
- Struggle to be relevant
- Struggle to be enterprise-wide
About a year ago, my team was engaged on an enterprise problem commonly known as Enterprise Strategic Planning, which for us was about addressing three CIO concerns for the purpose of portfolio management/funding allocation of project dollars. The portfolio managers need to know:
- IT and Business Alignment
- Gaps and Overlaps
- Technology Investments
At this point, we could have participated to support the Enterprise Strategic Planning effort by delivering things noted above as a traditional Enterprise Architecture would. Instead, we decided to take a different approach. We decided to adopt the Service Provider business model equipped with Service Offerings. We call it Enterprise Strategic Planning (ESP) Service and our Service Offerings include; ESP Collaborative Process, Roadmaps, Analysis, IT Proposals, Standards Alignment, and Enterprise Model/Taxonomy Maintenance. All of these are geared to delivering direct value to IT organization’s planning needs.
Mind you, we use Conceptual Information Models, principles and standards, etc but this is primarily behind the scenes and they often don’t surface in discussion unless one of our stakeholders asks a probing question of our service offerings. This is important, I’m not suggesting to ignore delivering traditional EA artifacts like CIM, position whitepapers, etc. We deliberately use them to ensure our offerings are of high quality and fidelity. High quality and fidelity are important characteristics of our brand we must manage carefully.
The paradigm shift is moving from a traditional Enterprise Architecture team to a Service Provider. We manage the ESP Service as a product line with offerings, we have a business plan, we have a strategy, we have a market with competition, we have a balanced scorecard to monitor our success to our strategy…just like any well-managed business.
A couple of interesting outcomes that are largely due to this shift:
- We no longer have the challenges mentioned above. We deliver value with explicit associations to enterprise problems. We are more influential than ever because we have voting-rights on enterprise decisions, We are highly relevant to important decisions as evident by our engagement with our company’s top brass. We are only engaged on enterprise-level problem areas.
- I don’t have the additional problem of having to sell Enterprise Architects. Previously, I would have to take time to explain how an Enterprise Information/Business/Infrastructure Architect is relevant to problems and decision making. Now, I simply deliver an offering that is required for a decision affecting our enterprise to occur. I hire Enterprise Information/Business/Infrastructure Architects to deliver the offering.
- I don’t have to ask to be influential. Our offerings are a requirement. Our deliverables are not an option. Because they implicitly have our thinking built-in, they influence our organization implicitly without having to spend a tremendous amount of effort winning relationships. Btw, I’m not saying we don’t require unbelievably strong relationship skills (aka emotional intelligence), we do.
My suggestion to you all is “Don’t build Enterprise Architecture teams/functions to have Architecture. Instead, solve enterprise problems with Enterprise Architects.”