How can you incentivize the right behavior so that your enterprise architect (EA) doesn’t become 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 reviewsContent you might like
Yes18%
Yes, but only the traditional IT department.41%
No38%
Unsure1%
Other (please comment)0%
529 PARTICIPANTS
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%
3982 PARTICIPANTS
Chief Information and Technology Officer, 1,001 - 5,000 employees
Create a roadmap. Start with the requirements and build a plan based on business objectives — why do you need a resilient technology architecture if there's no requirement for it? Then you create strategies to achieve ...read moreChief Information and Technology Officer, 1,001 - 5,000 employees
We put a roadmap in place with a defined methodology. We’ve been using the OGSI methodology for a very long time, which aligns the IT organization with the company's business imperatives up to two or three years down ...read moreChief Information and Technology Officer, 1,001 - 5,000 employees
If you're a technologist, you want to work on the latest and greatest tech, and if you're not getting that from your current organization, you'll find it somewhere else. As a manager, you need to be able to give ...read more
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.
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.