Enterprise Architecture

Enterprise Architecture

I few years ago, I had the opportunity to take a fantastic TOGAF (Enterprise Architecture) course with Professor Atila Belloquim from Gnosis Knowledge Solutions . I'm sharing some class notes:

  • Enterprise Architecture has nothing to do with building constructions, but with business management.
  • Architecture is a metaphor for the plans that describe an organization's components: people, processes, technology, infrastructure.
  • Enterprise Architecture isn't about "aligning IT with the business." It's about "aligning strategy with execution."
  • If the strategy doesn’t trickle down to operations, it becomes merely a record of good intentions.
  • Enterprise Architecture is not IT Architecture. It encompasses IT Architecture, is often driven by IT, but is larger than it.
  • The Architecture needs to be Corporate. The business needs to be involved. Technology is just a part. It’s not the architect who does everything.
  • Enterprise Architecture is a process, not a project.
  • Integration, traceability, and reusability are the keywords that define the purpose of Enterprise Architecture.
  • The area of Enterprise Architecture itself is like a company that provides services to the rest of the company.
  • Cultural and political factors are the most important (and neglected) aspects in adopting a methodology. Don’t even think about implementing Enterprise Architecture without considering cultural and political factors.
  • Organizational culture are the beliefs and values shared by the people of the organization. Beliefs are things people think to be true. Values are the things that say what is good and what is bad.
  • What is privileged in the organization? What is punished? What are the beliefs behind it?
  • Politics are the formal and informal power relations that affect the execution of projects and the day-to-day operations of the organization.
  • Where there is more than one person, there is a conflict of interests.
  • Agency Theory (microeconomics): everyone working in an organization should follow the objectives of those who hired them. But humans don’t function like that. Each hired person (agent) will have their own personal goals.
  • Much of human resources practices exist to solve the agency problem. Bonuses, profit sharing, goals, and performance evaluations exist to encourage the worker to achieve the company’s objectives.
  • Nobody adopts a process without changing the culture. Nobody changes the culture if the process is complex.
  • A good process, a good methodology, is one that is used. To be used, it needs to be simple, without bureaucracy.
  • Just because you know PMBOK doesn’t mean your projects will be successful. Just because you know TOGAF doesn’t mean you’ll implement Enterprise Architecture. They are necessary, but not sufficient.
  • You don’t implement PMBOK, you don’t implement TOGAF. What you implement is Project Management, is Enterprise Architecture.
  • If you don’t customize TOGAF, you're making a mistake. To customize is to reduce, not increase. You should adopt what is necessary and leave out the unnecessary.
  • If you put a PMP in a project designed to fail, it will fail anyway.
  • SWOT Analysis: companies usually have more information about what is outside the company than about what is inside. Companies are black boxes to themselves.
  • Enterprise Architecture needs a process; which generates a content; which is stored in a repository.
  • You need a housekeeper precisely because the house is dirty. You need Enterprise Architecture precisely because the company is a mess.
  • Mission: the reason why the company exists. Vision: where the company wants to go. Strategy: how to get there. The Strategy can change without the Vision changing.
  • Baseline Architecture is the "as is." Target Architecture is the "to be." Between these may exist Transition Architectures, which are the "roadmap."
  • Every project should be linked to the company's strategy.
  • Quality is not just software with fewer errors.
  • Enterprise Architecture (which encompasses strategy and business) is different from Solution Architecture (which focuses on technology).
  • If the solution architect becomes an auditor, (s)he becomes a bottleneck. If (s)he becomes a bottleneck, the solution architect will lose political power and be hated by the company. (S)he will be demoralized towards the corporation.
  • If you don’t look at all domains (business, applications, data, and infrastructure), you are not doing Enterprise Architecture.
  • Technology cannot make business decisions. It needs to translate technical possibilities into business terms (time, cost, performance, flexibility, risk).
  • The architect suggests, indicates, shows pros and cons. The decision is made by the Architecture Committee, composed of key stakeholders, business executives, legal, CIO, etc.
  • A forum is consultative. A committee is deliberative. The forum should lead to decision-making for the Architecture Committee.
  • Instead of creating a new committee just for Enterprise Architecture, an existing Senior Committee can be used.
  • If at every decision-making the Committee doesn’t find the principles to be followed, then they are incomplete. If the Committee violates the principles all the time, then they adopted the wrong principles.
  • The implementation of Enterprise Architecture has two challenges, one strategic and one operational. The strategic is to get sponsorship. The operational is to get a tool.
  • The idea that someone can do Enterprise Architecture without tools is incomprehensible.
  • When a company applies TOGAF and succeeds, it doesn’t publish so no one copies. When it doesn’t succeed, it doesn’t publish to avoid embarrassment.
  • IT people are generally very bad in the sales area. First mistake: offering the wrong product. Second: making the offer the wrong way. Third: making the offer to the wrong audience.
  • The architect needs to identify the client's pains, problems, and desires; then show that he has the solution for these pains and desires. The name of the product doesn’t matter.
  • Selling to the client is the "show time".
  • Instead of using "success cases," we can use "disaster cases": show how much time and money was wasted on projects carried out without Enterprise Architecture.
  • To implement Enterprise Architecture, one can "hitch a ride" on a larger project, such as the implementation of an ERP, the merger/acquisition of companies, or a priority project for the manager/sponsor.
  • There are three types of projects: the "coffee break" (low impact and risk); the "normal" (medium impact and risk); and the "camping" (high impact and risk).
  • Knowledge Management is not just one portal on the intranet.
  • Stakeholder management helps avoid the "ghost train" (identifies who will pull the rug) and find the "secret friend" (who could be helping and isn’t).
  • A single repository is indispensable in the case of segmented Enterprise Architecture teams.
  • If the Vision is clear, we can start by designing the To Be, avoiding getting stuck in the documentation of the As Is and being influenced by it. If the Vision is not clear, we should start with the As Is to identify opportunities for To Be.

And a bit of corporate humor!

  • Criteria for project approval: the size of the boss's badge and decibel (who shouts loudest).
  • Pet Project: a project implemented by someone who has money and power, but without alignment with the company's strategy.
  • MBRM: management by reading magazines.
  • Shadow IT: the more spreadsheets a company has in production, the more Technology is disconnected from Business.
  • The most used platform in the world is not Cobol. It's Excel + VBA.
  • After IT replaced O&M, twenty years passed without us looking at the processes. Then, twenty years passed looking at the processes, without looking at IT.
  • Past lives therapy: the Business Analyst is the reincarnation of the O&M Analyst. SOA is the reincarnation of Object Orientation. Big Data is the reincarnation of Datawarehouse/Datamart/Datamining. Cloud Computing is the reincarnation of the Service Bureau.
  • NIH Syndrome (Not Invented Here): if the idea wasn’t mine, it isn't good.

Share this article with your colleagues!


Eleazar Chavez

IT System Specialist

8 个月

Great hints, some times as architect, just we suggest and provide the best practices. ??

Mehak Suri

Enterprise Architect | Technology Strategist & Advisor enabling business digital transformation with expertise in Enterprise Architecture and Integration.

9 个月

Great notes, underlining the practical aspects of Enterprise Architecture. Couldn't agree more- "Enterprise Architecture isn't about "aligning IT with the business." It's about "aligning strategy with execution." Thanks for sharing.

要查看或添加评论,请登录

社区洞察

其他会员也浏览了