Technology continues to disrupt long-established roles across business and IT, including that of the enterprise architect (EA). As the former Chief Architect and CTO of JPMorgan Chase, Adrian Kunzle knows this challenge all too well. For the latest installment in the ongoing “IT Visionaries” series, Kunzle, now SVP of Product Development, Platform at salesforce.com, gives his take on the current enterprise architecture landscape and how one can best evolve to adapt.

 

 

Adrian-Sidebar1. Where have enterprise architects typically gone wrong in the past?

They haven’t been particularly good at convincing the people that had to do the work that what they were saying was right. Describing the value of a particular architectural approach is hard. Additionally, the architect brand is very much tainted with this notion of an “ivory tower function,” where the EA from up on high casts tablets of stone down and says: “Build systems that way.” And everybody on the ground says: “What do they know. I’m actually in the trenches trying to do the work. I have to make compromises and what the EA is saying isn’t practical.” The thing about about software is that they actually can make their own decisions.

2. Is there any way to get control of what and how systems are built?
 

Decisions are always going on. It’s the people making those decisions, your developers and team leads, that are your control points. And often they aren’t working directly for you. The EA function is one of influence, which makes credibility all the more important. The only way I’ve worked out to offer direction to this group is to respond to what they are trying to do all the time, which is build systems as cheaply and quickly as possible. What I did as an EA was try to produce tooling, frameworks, and services that were simply faster and cheaper to use than them going out and buying their own or leveraging open source. Of course, this isn’t the only thing an EA function should do. It still needs to govern and review projects, and mine standards, policies and best practices from the broader IT organization. But those are topics for another day.

3. How should enterprise architects provide this kind of framework?


The first line of code a developer should write should be a line of business code, not a line of plumbing. And that’s part of a mantra for platform services. Developers should not be worrying about how they are going to connect the app server to the database, whether they’re going to use an object or relational mapping layer, or whether they need a messaging technology. All that’s just there. So the first thing they’re doing is thinking about the business problem they’re going to solve. There are some developers who want to think about the plumbing, and those are the ones you want working on the tooling and framework, not the business problems.

4. Does this development environment need some flexibility?

Yes. You’ve got to be out there listening to the customer because they’re always going to be challenging your assumptions in that stack. If you’re not hearing them or cooperating with their preferences, you end up with this drift where what you’re providing is becoming less and less what they want to use. There’s a fine balance. Your developers may want to tweak or adapt or add their own testing framework. If you make the stack too rigid or the content is not applicable enough to the developer, they won’t want to use it and will go back and build in an environment that better suits their needs.

5. What’s the secret for working with developers and the Business?

EAs have got to be a trusted partner to both. It’s kind of a tricky situation because it forces them to behave in two conflicting ways. On the one hand, they need to convince the developers that the technology decisions they're making are the right ones. But they also need to spin all that technology around and frame it in business terms and engage with business partners on what matters to them. What the business is after can drive real architectural principles. If the business doesn’t trust you, you have to lean on metrics to demonstrate the benefits. If the business trusts you, it’s much easier, but metrics are always important.  

Adrian-Quote


6. Do EAs ever reach a so-called target state architecture?

I think architecture is something that evolves. You’re always trying to get to a better state, but you never reach a perfect state, Your business is constantly changing. Technology, software, and hardware are changing. You need a set of guidelines and principles on how you want to move things forward, such as, it needs to be mobile-first. Or it must support rapid testing of new business offerings. These principles often last many releases, so they will help anchor your architecture to business needs. When those business needs do change, so do the principles. It is then that you have some serious work on your hands to re-shape the architecture for the new constraints. But I don’t believe you never reach a target state. It’s very much a journey.

7. Why do you refer to enterprise architects as “archeologists”?


Architects need to regularly question whether previous assumptions made by an organization are still valid. This manifests itself in decisions around tools, data sources, scale, and many other things. It’s a constant process of digging through systems that have been ignored for a while. A system may have been built to handle ten-thousand trades a month and then the business took off and suddenly you find it five years later doing a million trades a month. That’s when you need to go back and start doing the archeological piece. Because invariably, the person who designed it isn’t available. So you have to discover why decisions were made, work out which ones are now invalid, establish new ones, and change the architecture to get it back to a healthy state.


Do you want to focus more on driving business growth instead of infrastructure? Do you have the tools to innovate faster in a social and mobile world? Is Platform as a Service for you? This e-book cuts through the buzz to show the benefits platform as a service (PaaS) delivers from the recognized cloud platform leader, Salesforce.

PaaS