/* Google Analytics ----------------------------------------------- */

Saturday, July 11, 2009

How to be a Good Enterprise Architect?

I would like to share some lessons learned concerning the job of Enterprise Architect.
  1. Create the team charter. Describe what you team role is and what are your main objectives. This charter will never be read by anybody, like this blog, but you need to do it.
  2. Communicate. You must begin by creating your own communication channel, for me at least an intranet web site, a wiki and an EA internal newsletter. In general, since you will not have any budget for it, it is a good way to learn HTML and web site design best practices.
  3. Create Enterprise architecture principles and technical standards. This will give all people a clear framework to work with. All technical standards should be defined if possible with Procurement and Legal, in order to facilitate the work of project team. Create also an exception process, and document all rationale for exception. This will of course create an army of enemies: developers (you never select the tools they want), project manager (with your standard, it will take more time and cost to do my projects) and also suppliers (lobbying projects and VP to use the exception process).
  4. Document everything. Every technical decision should be documented (use a wiki and make it short), every meeting should have minutes, and all technical document should be produced (use an ad hoc EA tool or standard EA document templates. For example for each project you should provide: Service Level Agreement, Non functional requirement, Architecture description, Security architecture and impact analysis of your project on the IT landscape. In order to avoid any issue, make sure that documentation is a required tasks in ANY development process used. In general, you will get millions of documents in different formats (Microsoft Visio, excel, powerpoint with circles and square) and you will get the famous sentence: "I'm so busy i do not have time to document" or "Between documentation and features, I prefer features".
  5. Define quality rules and put in place the tools to assess them. This is true for architecture, code, integration, data, etc. You need to be able to build a dashboard for each application or Key business process. Quality is not part of performance evaluation of a project manager, so, be ready to loose battles. More than that, bad quality code is a way of keeping a high technical debt leading to always more maintenance, cost and resources.
  6. Use two EA frameworks. Use Togaf 9 to run you EA shop and create an adapted EA framework for making the company EA (with a clear modeling guide). Create your framework independently from the tools, be portable. Begin small, with all data you can get and not by all data you want to get (having to see empty set of information is depressing). If you're working in North America, you may have to use a specific gov or defense EA framework. Using your own framework adapted to your company maturity and EA KPI and concerns you will be considered as an alien, and excluded from EA groups and will never be able to get EA certifications.
  7. Use a unique EA tool within the company. This is the most important think to do to ease your life, use a unique and centralized EA tools. Implement your frameworks within this tool. You will then spent thousand of euro configuring, using, and deploying a tool that nobody will use (except yourself). The only thing people will tajke care of is the web site export of your EA tool content and the colors and icons used will lead to great debates.
  8. Ask Good questions, make Good recommendations. Follow your line, do your job sincerely, stay polite, ask the right questions, follow the standards and make the right recommendations. Then if decisions are not going into what you think is the right directions, then document the possible issues and the risks. Be ready to be treated like a treator, to be excluded from discussions, to be invited to meetings where everything is already decided and where people just want your sign off, to get business provided solutions instead of questions. In crisis mode, Keep It Simple Stupid (KISS) is the law and nobody wants you to look bright. Several years later, you will have to cope with the errors made anyway, since people making bad decisions are very keen on leaving the company.
  9. Build a team and mentor your troops. The lead architect should build a team (direct report or not) and mentor as much as possible. You do not need to be better than all your architects in all subjects. You just need to trust your team and ensure proper discussion of all technical subjects. Challenging each others decisions is also a good way to be ensured that you'll take into account all possible views on a unique problem. This is a long and painful task, be ready to accept to change your mind when you're wrong and eventually to pay some beers if you've lost some bets.
  10. Be innovative at technical but also at business level. Try to understand the organizational patterns in your company and push some innovative solutions when possible. Innovation does not mean testing everything is new!
  11. Keep your team up to date with technology / business trends. The best way to do it is to make the EA got to selected conferences, offer regular trainings and invite them to buy and READ a couple of books every year. Try also to free some percentage of their work time to enable thinking, research and testing. Be careful, some EA will be very keen on accepting external meetings and spend their time doing marketecture (marketing and architecture).
  12. Bridge the Gap with Business and IT OPS. EA architect is the best person to bridge the gap with different groups, since by nature its scope is crossing the silos. Especially, try to define commonly created deliverables and meetings in order to ensure the proper collaboration and synchronization. It is also a good way to get the knowledge you need on the advancement of each projects.
  13. Test everything in your environment (cultural, technical). Never trust the brochure.
  14. Build your network. EA needs to be connected to at least the key technical people in the company, the key company suppliers and the key business people. Finance, legal and procurement are also important people to discuss with. I also recommends to go and see how what your building is used by your field employees and your clients. If you can afford to do it, try to get a subscription to access Forrester, Gartner or any other consulting services. User groups are also a very good opportunity to discuss with your peers. That's why having an EA tool is also a good investment!
I hope this will help you doing your job and understanding that being an Enterprise Architect is great and sometimes "dangerous" for your health.