| September 2006 |
| By Lu Wang |
When someone mentions the words Enterprise Architect, what image comes to mind?
When I was doing application development and later application architecture, the title Enterprise Architect actually conjured up the image of a wise old man, sitting in his office masterminding a grand vision for IT, and at the same time, telling me what I'm doing wrong with my projects.
Now that I've been doing Enterprise Architecture for a major US grocery retailer for more than 3 years, I can tell you I don't fit that description at all, well, maybe the grand vision for IT part, but I digress.
The shortest description for EA is "a process that aligns IT investment with business strategies". I know it sounds a bit ambiguous, so I'll elaborate further.
At a high level, I work on defining the logical architecture (the types of things we need), the baseline architecture (what we have right now), the target architecture (what we need in the future), and the migration plan (how do we go from baseline to target). I also create principles, set standards, promote best practices and provide architecture governance.
Usually, the whole enterprise architecture is too big a pie to take on, so each EA organization needs to decide how to divide it up.
The way my company divides it up is by domains. The domain I’m focused on is the retail domain which includes all business processes, information, organizations and technologies inside the retail store. The retail domain architecture is a fairly large piece in itself, so I’m taking an interactive approach to it. I spend a lot of time talking to people, either in formal meetings or in hallway conversations. I’m trying to identify within the business, the biggest opportunities for improvement by making them retail architectural iterations in order to drive the architecture top-down and across business, information, systems and technology layers. In a sense, I’m “thin-slicing” the retail domain architecture. The end goal is to have a target retail architecture that enables business agility and maintains business continuity. The moving target architecture then gets translated into programs, the programs are then translated into projects that deliver discrete pieces of functionality.
The other large area that EA focuses on is architecture governance. It’s not just about slapping project teams’ hands and telling them what not to do. Instead, I use it to help the project team be successful and at the same time to ensure project alignment with the overall enterprise architecture. The best way I found to achieve this win-win result is to establish a good relationship with the project team, help them with their questions and show them the big picture. What gets done before the architecture review meetings is more important then what’s decided during the meeting. During the architecture review meetings, I try my best to give concise and unambiguous answers, and ask the most important questions. A lot of times, I’ve communicated with the project team before the meeting, and they knew what I would be asking – no surprises there. Having taken on the application developer, tester, business analyst, team lead, designer, architect and project management roles also helped me a great deal to empathize with the project team’s concerns and challenges.
In order to be a successful EA, one also needs to understand the popular EA methodologies and frameworks on the market, which are more similar than not. One also needs some in-depth knowledge of enterprise technologies such as J2EE, .NET, UML, MOM etc... An EA also needs to understand and speak the language of the business people, understand their motivations and help them transform their businesses.
As in any job, many soft-skills are required as well. An EA needs to have strong leadership, decision-making, influence, communication and management skills.
The grocery retail business is very unique, it’s a very high-volume, low-margin business. The business folks are really good at driving down costs. It’s a challenge to get business executive to think long-term and strategically. Fortunately, we are moving in the right direction. I didn’t have a retail background when I joined the company in 2001 and learning how the business makes money really helped me learn the language, so now I can focus on the company’s concerns.
It took me 10 years to go from an application developer to finally reaching EA. It's a long journey, and there were numerous necessary "paradigm-shifts" along the way. Enterprise Architecture is still a fairly new discipline within IT, and it has the potential to greatly impact how strategic planning and execution is done in any industry.
My advice to those of you who aspires to become an EA are:
- Get to know your business
- Get to the know the right people inside your business and IT
- Learn to do architecture at the project level first
- Learn the soft-skills (especially for us techies)
- And most importantly, demonstrate your ability to strategize, execute and influence the outcome
If you would like to submit an article providing an insider’s view of your tech or engineering job, please send your article to us at ITtrenches@dice.com.
Comments on this article? Share your feedback on our discussion forum, Dice Discussions.
*Please note, you must be a registered job seeker in order to submit your question to Dice Discussions.
|
|
|
