How can you incentivize the right behavior so that your enterprise architect (EA) doesn’t become a blocker?

2.3k views1 Upvote7 Comments

CIO / Managing Partner in Manufacturing, 2 - 10 employees
It depends on how you define the role and therefore, how you define the reward. What behavior are you rewarding — what does good look like? And what's bad? Bad enterprise architects (EAs) are rewarded for defining the pattern and pushing everybody to adhere to that pattern. When I look at the EA as a senior solution designer who’s considering the whole, I’m looking at how we are delivering business value as an entire group and their role in designing that key piece of it — how are they contributing to help design that future? How do we move the business forward? If we're not looking at how we move the business forward then IT is failing. We're not doing IT for IT sake.

As a practical example, one of the things we did at a particular organization was moving our ERP to the cloud. We also brought in MuleSoft to provide an enterprise service bus in order to move away from point-to-point integration. Both of those projects were driven by our enterprise architect when it came to how we moved forward and how we would add value to the business. There was direct business value from both of those changes. Moving the ERP to the cloud made a significant impact because the ERP had been holding the business back in terms of their ability to produce and deliver to customers. That’s tangible business value.
1 Reply
Advisor | Investor | Former CIO in Services (non-Government), Self-employed

When it comes to enterprise architecture, the reward system is one of the biggest issues that I've observed over the years. When you don't have the right set of incentives in place, the EA becomes a blocker.

CIO Strategic Advisor in Services (non-Government), 2 - 10 employees
There are a lot of folks building these enterprise architecture fiefdoms who would say that what they're doing is providing value, and that it is a necessity for the organization. But how do you measure that value? And how can you start to understand the purpose of architecture in a way that a layperson, someone outside of IT, can look at it and say, “We can't do this without that. Enterprise architecture is valuable to us.” The challenge is that within IT, we get so wrapped up in the idea that we're providing value even when we might be the ones that are dragging our feet. 
Solutions Architect in Manufacturing, 10,001+ employees
it think you need define architect (deploy) solutions? or achitect infreastructure?  the process for the architect (deploy) will be define goals and dates along with your deliverables.
I have always thought that each person is motivated differently, it is a bit heavy work to identify the motivator of each one, but not everyone is motivated by money, prizes, recognition or a pat on the back
Vice President of Engineering, Self-employed
You're looking for metrics that define a job well done by the architect. Specifically what do you want out of your software development team? I try to push as much as possible to the ICs, so architects, QA, product managers typically work as consultants to the ICs tasked with developing software. Their job is to accelerate the ICs and help them have a complete view of what they're developing.  

So I focus on "evolutionary" architecture -- principles that are built for making rapid evolution of our software possible safely. Therefore the architect's job is to talk through a story or an epic with the principle IC involved in developing it, and then to provide periodic "lightweight" review of decisions and documentation about those decisions.

If you have an architectural review step, set expectations about how long a project sits in that step. Or revisit the idea of having one at all and add architecture into the review and grooming processes. This means you have to increase the autonomy and trust levels you put into your ICs, but if you do that you're generally rewarded with better velocity and better developer engagement and retention.  

Overall the less engaged an architect is with the software developer's daily grind, the more aloof and the more "blocky" an architect gets. The more context they lack, the more they have to deal in abstract principles and the less useful they are to good software development. 
Chief Technology Officer in Software, 501 - 1,000 employees
This is a very complex topic and without more context it's hard to give solid recommendations but some general issues with EAs tend to be:
- Ivory tower syndrome
- Post technical and out of touch (or worse, vendor driven)
- Disconnected from business outcomes
- Too many of them

Writing objectives, or whatever you use for incentives, to address these points goes a long way to making architects in general enablers rather than blockers.
Venture Partner, VP Products, Chief Product Officer in Energy and Utilities, 10,001+ employees
Open transparent discussions using design reviews

Content you might like


Yes, but only the traditional IT department.41%



Other (please comment)0%


1.4k views1 Comment

No plans on undergoing a migration yet34%

Currently deploying SAP S/4HANA28%

Migrating to SAP S/4HANA within the next 1-2 years19%

Migrating to SAP S/4HANA within the next 3-6 years10%

Already have SAP S/4HANA in production8%


31.2k views154 Upvotes32 Comments