"Architecture is about doing the right things right."
Absolutely Alan! Nice elevator pitch.
When reading Alan's blog what made me a little uncomfortable was the apparent decoupling of "Architecture" from "Management"...
As EA's we look to the Enterprise (organisation/business unit) to understand its business, its business processes and how its IT assets are supporting them. We should also have a solid understanding of the Value Chain within the Enterprise, so as to best understand where Value is being added either directly or indirectly.
For EA to work effectively it has got to be embedded into the boardroom. The CxO's must be confident that IT will enable the business to meet its objectives and support the EA function. For this confidence to be build within the boardroom the Enterprise Architecture value contribution must be known to the board members.
Some examples that spring to mind:
Proactive Contributions (upward looking)
- Cost Reduction
- Consolidation
- Data Centres
- Systems
- Applications
- Decommissioning (Switching things off!)
- (Business) Differentiation
- IT Innovation
- Cost projection
- Do the CxO's understand the full life cost of the programmes
- Do the CxO's understand the ROI
Reactive Contribution (downward looking)
- Project/Programme Cancellation
- EA's spot a project is going bad...
- Quality Assurance
- Technical Deep Dives
- Solution delivered matches requirements
What you probably don't want (as an EA) is your CxO telling you they want 20%, 40% or 80% reduction in IT spend: As an Enterprise Architect you should have a strategy in place which means the Enterprise IT service offered to the business is efficient as practically possible.
So, getting back to Alan's blog, my extension to the elevator pitch would be -
Enterprise Architecture is nothing without adding value and assuring delivery; sometimes stopping delivery - for the right reasons - is a good thing...
2 comments:
"Enterprise Architecture is nothing without adding value and assuring delivery; sometimes stopping delivery - for the right reasons - is a good thing..."
Interesting, but I would disagree. I see EA as a strategy or framework which can be delivered in any number of ways.
Assure/ensure/insure feasibility yes, but not delivery. For me that responsibility lies with the programme/project manager. Is it really advantageous to couple a blueprint to a methodology?
Interesting juxtaposition of points....
Putting the blueprint & methodology to one side for a moment Jez.... (nice beer btw)
Considering EA as a function within an organisation, rather than something that is "delivered" in its own right; a key aspect of EA is governance - assuring the delivery is fit for purpose and aligned with the original vision. Within the EA function this may be achieved by the solution architect reporting back to the EA governance body or some other reporting function (deep dives etc).
Accountabilty for the delivery schedule/financials clearly resides within the PM domain. Accountability for the technical solution resides within the technical team.
EA should be "business as usual" within the Enterprise; however, if you're establishing EA within an organisation you need to be clear how it adds value to the organisation first and foremost. Once EA's contribution to the Value Chain is understood, then an EA practice is more likely to succeed. Should the EA practice stop the projects where the "regret cost" is high, then this is a clear example where the practice is adding value.
Post a Comment