Is there an orthodox method to becoming an enterprise architect? I have looked into getting TOGAF-8 certification, but aside from that, what type of business and technical experience will I need to overcome?
+10
A:
Really, there isn't. In fact, there's very little agreement to what exactly an "architect" role ought to be.
Having been in an architect role for most of 20 years now, I think the things you really need to concentrate on are:
- Understanding the nonfunctional or quality requirements, like security, safety, reliability, availability, scalability and throughput/performance.
- Understanding the large scale patterns of architecture (see, eg, Fowler's book on patterns of enterprise architecture)
- A good understanding of the benefits and tradeoffs involved in different project organizations and methodologies (eg, XP, SCRUM, spiral etc)
Charlie Martin
2009-01-08 01:29:28
+7
A:
The normal route is project architect, domain architect, and then enterprise architect. But these are all heavily overloaded terms, and their meaning can differ from company to company.
In general, qualifications don't help much. In my experience, the primary factors in descending order of importance are:
- Who you trust and especially who trusts you - communication and networking.
- Succeeding in project and/or domain architecture - your experience.
- Skills, talent, and technical/domain knowledge.
- Qualifications, because they show technical knowledge.
First focus on the senior architects, senior IT management, and senior business people at your company. Understand (from the architecture viewpoint) what drives them and what's important to them.
Then focus on gaining domain knowledge and associated architecture knowledge, and on becoming a domain architect. For example, what are the major business processes, and which IT systems handle these processes? What is the complete data life-cycle?
Finally, bring the two together to create some convincing stories about how enterprise architecture really can benefit the company (TCO is a good buzzword here). You may need to convince yourself first :-)
Like any technical role, once you start behaving like an enterprise architect, people will start treating you like one. At some point, this should translate into an official role. Bear in mind that you may need to jump companies at some point in this process if you want it to happen faster.
RoadWarrior
2009-01-08 01:49:23
+1
A:
Architect in software engineering terms is almost a misnomer. I think in all but the most formal software environments, the architect role isn't needed at all. What you need are senior/expert developers to lead a team.
Senior developers are able to understand the high level without losing sight of the low level. They know how to ask the right questions of the users/customers to understand what is really being asked for. They are experts in their field and most importantly in their domain.
sliderhouserules
2009-01-08 01:51:04
I think enterprise architecture really is required at big LoB companies. The project/team architects can't really focus much on the enterprise-wide issues. Domain architects do work at a higher level, but big LoB companies usually have multiple domains.
RoadWarrior
2009-01-08 02:01:38
I missed that he asked about being an enterprise architect in his question. Systems integration and all the other stuff an EA has to worry about is quite a bit different than most of the "architects" I've worked with over the years.
sliderhouserules
2009-01-08 08:24:25
A:
the typical method is to architect an enterprise solution. You may have to build it yourself.
It doesn't necessarily have to work. ;-)
Steven A. Lowe
2009-01-08 02:07:06
A:
Being an EA, or more accurately a CEA, certainly means an understanding of technologies used to fulfill stakeholder requirements, while adhering to a hierarchical architecture. You don't have to be a master of every little facet, but rather that a specific technology can, at a high level, meet the needs of a customer.
Think of EA as big picture designing and describing (BPM).
You can plow though the TOGAF, DoDAF, and FEA. Most US government agencies are required to publish their architectures so you can peek there.
Black Cat
2009-01-08 02:18:15
A:
have a firm grasp of buzz words and make sure your nontechnical bosses hear you use them both with developers and with them. Explain the buzz words to your bosses. No, I am not one! :)
Jesse Pepper
2009-01-08 04:43:48
A:
I recommend the following:
- Learn the language of business
- Find a mentor who is already an enterprise architect and emulate their approach to problem solving
- Work on public speaking and improve your communication skills
- Learn the basics of accounting
- Become a better developer
This is in priority order...
jm04469
2009-05-02 12:11:23