Arquivo da categoria: Soft Skills

Certificação TOGAF em 5 passos

Olá pessoal!TOGAF 9 Foundation

Recentemente passei na primeira prova de certificação do TOGAF versão 9.1: TOGAF 9.1 Foundation. Neste post vou descrever os passos que segui para fazer a prova com bastante confiança – afinal, uma reprovação implicaria em um prejuízo considerável (cerca de US$ 210,00 pagos pela prova feita através da Prometric).

É fato que cada um tem sua própria forma de aprendizado e que algumas coisas que funcionaram para mim podem não funcionar para todos. A sugestão é que você adapte estas dicas para a forma que melhor lhe atenda. Dependendo do seu nível de conhecimento atual sobre o assunto, você poderá considerar passos adicionais aos que estou listando abaixo, ou então a eliminação de alguns deles. Vamos lá!

Continue lendo

Porque projetos de TI demandam tanto esforço, energia, custam caro e ainda por cima atrasam?

Você já deve ter se deparado com esta questão em algum momento da sua carreira, ou quem sabe nunca deixou de se deparar com ela. É claro que são diversas as possíveis causas para ineficiência em TI e este post não tem a pretensão de abordar todas elas. Ao invés, vamos abordar uma das principais causas, tratada anteriormente por autores como Martin Fowler e Uncle Bob: Technical Debit ou Dívida Técnica (tradução mais fiel, em minha opinião). Além de materiais escritos pelos tais autores, encontrei também excelentes posts a respeito no site da InfoQ, no blog do Adriano Tavares e, claro, na Wikipedia.

DefiniçãoDevo, não nego. Pagarei quando puder.

A dívida técnica é como um financiamento, ou uma aquisição de dívida qualquer em que há o pagamento pelo empréstimo do dinheiro (juros). Na maioria dos casos, a aquisição de uma dívida acontece quando o indivíduo ou organização opta por ter um benefício imediato, ao invés de poupar dinheiro para comprar sem precisar recorrer a um financiamento. Isso pode ser feito por necessidade, ou simplesmente por ser mais cômodo. Normalmente tal indivíduo ou organização tem ciência de que ao fazer isso pagará um valor maior pelo que está adquirindo e também sabe que poderá liquidar sua dívida no futuro, caso se planeje para isso.

Continue lendo

Shortsightedness in IT – Thomas Erl

Olá pessoal!

Oracle Technology Network ArchBeat PodCastQuantas vezes nos deparamos com as frustrantes situações em que uma determinada solução tecnológica, aderente aos padrões corporativos e que melhor atende aos requisitos não-funcionais estabelecidos, não pode ser aplicada em um projeto, seja por não haver tempo hábil, por exemplo, levando a adoção de abordagens que nem sempre trazem bons resultados a longo prazo?

Neste post gostaria de compartilhar um trecho de um podcast publicado pelo Oracle Technology Network, em seu canal ArchBeat Pod Cast, onde Thomas Erl – best selling SOA author, explica como tais situações normalmente se originam. Segundo Thomas, existe o que ele chama de miopia na perspectiva considerada na avaliação dos resultados de projetos, onde acaba-se sendo considerado apenas prazo, orçamento e atendimento dos requisitos funcionais como critérios que definem se um projeto foi ou não bem-sucedido, deixando de lado a qualidade da arquitetura implantada, o que acaba resultando em defasagem tecnológica, projetos que geram silos de informação e aplicações que atendem apenas a um propósito, consequentemente aumentando o custo de propriedade do produto produzido pelo projeto. Confira abaixo.

Miopia em TI

“… the criteria organizations use to evaluate project team performance, I think there still a lot of tactical emphasis on determining what was and what was not a successful project and by that I mean did it come under budget, did it come on time, did it meet functional requirements and those tend to be focal points when projects are assessed and it is easy to lose sight of the importance of what you are designing and the long term implications of what you are building when you are focusing more on the timeline, the budget and meeting the functional requirements within the primitives of that budget and timeline. And it is easier to meet those goals as you are being assessed by bypassing proper technology architecture and just getting developers to build something that works as per the immediate functional requirements and if you as a project manager are not being assessed based on the quality of the technology architecture, its compatibility with the surrounding IT enterprise architecture, its compliance to predefined standards, then there is no means of assessing that or regulating that, then there is no motivation to really emphasize that or make that part of the project cycle, because it will just use up more time and resources and will go against the other points which you are being evaluated. So I think that assessment from a strategic perspective is also lacking in some IT environments and that is to their detriment in the long term, because it is not part of how they assess project, applications, delivery projects, then those projects do became very much silo based, single purpose and then, consequently, impact the subsequent governance and ownership burden that IT enterprise assumes and it is that shortsightedness that I think also leads to situations like that where IT architects are not given the level of responsibility that they should.”

A não mudança de tal cultura leva a geração de conflitos constantes entre os times de projetos e os times de arquitetura, pelos seus diferentes interesses. A convivência em projetos com tais conflitos acaba não sendo saudável para nenhum dos envolvidos, nem tão pouco para o próprio projeto. Decisões de design que deveriam ser facilmente tomadas precisam ser escaladas para a gestão, o que acaba gerando ainda mais desgaste – quando não há politicagem – atrasos e posterior pressa para implementar o design decidido.

E por esta razão, acredito que organizações hoje tenham chegado a um nível de maturidade onde já enxergam a necessidade e os benefícios da adoção das disciplinas de arquitetura, porém, ainda precisam evoluir para um próximo nível, onde estarão aptas a de fato empregar eficientemente tais áreas em seus projetos.

A responsabilidade de um “profissional” de software

Olá pessoal!

Neste artigo gostaria de compartilhar um trecho do livro “The Clean Coder”, de Robert C. Martin (Uncle Bob), que trata de ética e conduta profissional para nós, profissionais de desenvolvimento de software. O trecho aborda dois tópicos de extrema relevância. O primeiro é sobre decisões políticas ou baseadas apenas em questões financeiras de curto prazo e o segundo é sobre a responsabilidade que um profissional de software responsável por decisões técnicas (seja um arquiteto de software ou qualquer outro papel correspondente) tem ao assumir tal papel.

The Clean Coder

Em um projeto, diferentes stakeholders demandam diferentes requisitos não-funcionais, muitas vezes conflitantes entre si. Gerentes de projetos, por exemplo, em geral priorizam o prazo estabelecido com as áreas de negócios (time-to-market). Áreas que manterão o sistema (que aplicação mudanças evolutivas / corretivas, por exemplo), demandam um sistema que seja modificável (modifiability). Um sistema projetado para ser modificável, em geral, leva mais tempo para ser construído. E esta aí o primeiro e mais comum conflito. A figura mais abaixo (extraída de materiais do Software Engineering Institute – SEI) representa este cenário.

Neste contexto, se por um lado um gestor tem a responsabilidade de não tomar decisões baseadas apenas em questões políticas e financeiras de curto prazo, um arquiteto de software tem o dever, a responsabilidade, de apontar de todas as formas possíveis, os possíveis riscos que uma determinada decisão de projeto (seja de design, por exemplo) pode apresentar.

Poor architectA história descrita por Bob Martin fala de uma decisão política / financeira, tomada em um lançamento de uma nave aeroespacial, que não levou em consideração os riscos levantados pelos engenheiros responsáveis, culminando na perda de sete vidas. Veja a seguir.

At 11:39 AM EST on January 28, 1986, just 73.124 seconds after launch and at an altitude of 48,000 feet, the Space Shuttle Challenger was torn to smithereens by the failure of the right-hand solid rock booster (SRB). Seven brave astronauts, including high school teacher Christa McAuliffe, were lost. The expression on the face of McAuliffe’s mother as she watched the demise of her daughter nice miles overhead haunts me to this day.

The Challenger broke up because of hot exhaust gasses in the failing SRB leaked out from between the segments of its hull, splashing across the body of the external fuel tank.

… The engineers at Morton Thiokol who designed the SRB had known that there were problems with the O-rings [SRB component that was identified as the cause of the incident], and they had reported those problems to managers at Morton Thiokol and NASA seven years earlier.

… The engineers had designed a repair for the problem, but implementation of that repair had been long delayed.

… In short, the engineers knew that the risk was too high. The engineers acted on that knowledge. They wrote memos raising giant red flags. They strongly urged Thiokol and NASA managers not to launch. In an eleventh-hour meeting held just hours before the launch, those engineers presented their best data. They raged, and cajoled, and protested. But in the end, the managers ignored them.

… Despite all the protest and memos, and urgings of the engineers, the managers believed they knew better. They thought the engineers were overreacting. They didn’t trust the engineers’ data or their conclusions. They launched because they were under immense financial and political pressure. They hoped everything would be just fine.

These managers were not merely foolish, they were criminal. … They made a decision they had no right to make. They usurped the authority of people who actually knew: the engineers.

But what about the engineers? Certainly the engineers did what they were supposed to do. They informed their managers and fought hard for their position. They went through the appropriate channels and invoked all the right protocols. They did what they could, within the system – and still the managers overrode them.

E por fim, Bob Martin conclui: ”… As an engineer, you have a depth of knowledge about your systems and projects that no managers can possibly have. With that knowledge comes the responsibility to act.”

É claro que como arquitetos de software muito dificilmente estaremos envolvidos em decisões que poderão implicar em vida ou morte de pessoas. Porém, é certo que determinadas decisões mal tomadas implicarão, a médio/longo prazo, em custos de manutenção e de propriedade mais altos, tempos de entrega mais longos (time-to-market) e em requisitos não atendidos. Quando tais problemas perduram, toda uma área de TI passa a ser mais um custo necessário, ao invés de uma área estratégica para o crescimento da companhia.

Who gets to be a software architect

Dilbert - ArchitectOlá pessoal!

Neste post gostaria de compartilhar um resumo do conteúdo de um podcast que ouvi recentemente, cujo tema principal era justamente o título deste post: “Who gets to be a software architect”. Acredito que o assunto seja bastante relevante, pois tem sido tema de diversas discussões em diversas comunidades, demonstrando que ainda há pouca maturidade e falta de consenso no mercado.

O podcast foi disponibilizado pelo Oracle Technology Network, no canal ArchBeat, que trata de assuntos relacionados à arquitetura. Para quem ainda não conhece, vale a pena conferir. O canal aborda assuntos diversos relacionados à arquitetura, tecnologias e tendências, como SOA, Cloud Computing, Governança, Enterprise Architecture, Business Architecture, etc.

O podcast consistiu em uma panel discussion, composta por quatro participantes de peso, além do Bob Rhubart, host dos podcasts deste canal. São eles:

  • Ron Batra: Oracle ACE Director, Diretor de desenvolvimento de produtos cloud computing na AT&T;
  • Brian Huff: Oracle ACE Director, Chief Software Architect na Bezzotech, Inc.;
  • Randy Stafford: Membro do Oracle’s A-Team – um grupo de arquitetos que trabalham em um grupo de desenvolvimento Oracle Middleware;
  • Eric Stephens: Enterprise Architecture Director, na Oracle;

A seguir consta o link para mais detalhes do podcast, onde também pode ser baixado o áudio: https://blogs.oracle.com/archbeat/entry/show_notes_who_gets_to_be_a_so.

Separei o conteúdo da discussão em alguns temas, que podem ser conferidos a seguir. Procurei manter o conteúdo fiel ao que foi discutido no podcast, sem incluir opiniões pessoais e sem alterar o sentido ou opinião dos participantes.

O que separa o papel de um desenvolvedor do papel de um arquiteto

Arquitetos caminham na direção de uma liderança técnica, enquanto desenvolvedores estão mais focados em tarefas de codificação. Arquitetos produzem especificações técnicas, diagramas arquiteturais, mas não focam em bits e bytes o tempo todo. O arquiteto estrutura o que deve ser construído. Ao mesmo tempo, arquitetos devem saber programar seu design. Os melhores arquitetos iniciaram sua carreira como desenvolvedores e posteriormente assumiram novas responsabilidades gradualmente.

O fato de estar longe da codificação não exime do arquiteto a responsabilidade de se manter atualizado, contribuindo para o desenvolvimento, o que aumenta sua credibilidade perante o time.

Alguns soft skills diferenciam arquitetos de desenvolvedores. Arquitetos devem saber influenciar, devem ter visão, liderança, devem saber trabalhar com times diversos, comunicar decisões arquiteturais / design.

“The developers are the ones who build skyscrapers, while the architect is someone who designs the city, while enterprise architects are the city planners.“

Diferentes papeis dentro do tema “Arquitetura”

Alguns exemplos de diferentes papeis dentro do tema arquitetura foram citados, demonstrando que ao contrário do que comumente é entendido, não existe apenas o papel do Arquiteto de Aplicações / Sistemas:

  • Infrastructure Architects: focam em detalhes de arquitetura de infraestrutura. Cluster, load balancing, firewalls, virtualização, servidores, etc, são temas recorrentes no seu dia-a-dia;
  • Integration Architects: SOA, EAI e padrões relacionados são suas principais preocupações;
  • Enterprise Architects: Conhecem o mapa de projetos / sistemas / frentes de negócios da corporação, estabelecem roadmaps de tecnologia e lidam com aspectos técnicos e também não-técnicos da organização.
  • Application Architect: Trabalham no nível de projetos. Em geral estabelecem e comunicam visões arquiteturais, que compreendem decisões de design de um projeto.

O título de “Arquiteto” deve ser reservado para aqueles que possuem certificações?IASA Carrer Map

Em geral, certificações mais técnicas focam em um produto ou framework especifico. Neste sentido, um profissional certificado será um excelente profissional para implementação de uma solução e-business, ou para identificar um determinado problema em uma base de dados ou aplicação java. Tais habilidades são extremamente valiosas para desenvolvedores / implementadores de solução, que em geral, procuram certificações para se distinguirem ou se destacarem.

Existem também organizações e certificações voltadas para as diversas segmentações dentro de arquitetura (infrastructure, information, business) e também voltadas à arquitetura corporativa (Enterprise Architecture). O IASA – International Association for Software Architects é uma organização que provê um mapa de carreira com cursos voltados para arquitetos e certificações relacionadas – veja imagem ao lado. O SEI – Software Engineering Institute também provê excelentes materiais e cursos relacionados à arquitetura de software. A Oracle também possui uma certificação voltada a Enterprise Architecture, chamada Oracle Enterprise Architecture Designation, além do Open Group, com o TOGAF.

Para arquitetos, além da competência técnica, habilidades de comunicação são cruciais. Normalmente, um arquiteto deverá passar sua visão para CIO, CTO, CEO, fornecedores, desenvolvedores, etc. Neste sentido, uma certificação não garante que o arquiteto seja competente o suficiente para realizar seu trabalho, já que é muito difícil certificar habilidades comunicacionais. Em geral, o que é levado em consideração na contratação de um arquiteto são suas experiências anteriores bem-sucedidas.

“The person (arquiteto) should have the ability to transcend one technology to the concept.”

Excelentes desenvolvedores podem se tornar arquitetos?

Se você é um excelente vendedor, não significa que você se tornará um excelente gerente de vendas. O mesmo vale para desenvolvedores e arquitetos. Algumas pessoas possuem profundos conhecimentos em bancos de dados, conhecem todas os truques para que o banco de dados ou o java faça exatamtente o que querem, e a forma mais rápida para resolver um problema em um sistema existente. Outras pessoas se dão muito bem quando trabalham em cima de requisitos difusos ou não claros.

É uma questão de mudança de ferramentas. Enquanto que para o desenvolvedor a principal ferramenta de comunicação é o teclado, para o arquiteto sua principal ferramenta deve ser o quadro branco e apresentações power point. Alguns desenvolvedores não gostam de se expor e não há nada de errado nisso. O mais importante é estar fazendo aquilo que se sente bem.

A discussão encerrou com o tema “hot-button issues” (más práticas), comummente cometidas por arquitetos.

  • Decisões “make or buy” devem ser bem pensadas. Por vezes, arquitetos ou pessoas com tal responsabilidade (CIO) decidem por manter e investir em uma ferramenta desenvolvida “in-house”, enquanto que comprar um pacote de mercado e investir em sua implantação pode trazer uma melhor relação custo/beneficio a longo prazo.
  • Um arquiteto não deve optar por tecnologias apenas por possuir conhecimento prévio. O benefício maior para a organização deve ser levado em consideração;
  • Um arquiteto nunca deve misturar diversas visões em apenas um diagrama. É comum encontrar componentes de infraestrutura, fluxo de dados, aplicações, regras e camadas de negócios no mesmo diagrama. Diferentes áreas de conhecimento devem ser representadas em diferentes visões / diagramas.
  • Excelentes comunicadores que não sabem desenvolver seu design não necessariamente são bons arquitetos.
  • Utilizar tecnologias apenas porque todos estão usando, ou utilizar tecnologias recém-lançadas, cedendo ao apelo comercial, não necessariamente é a melhor solução. Arquitetos devem saber selecionar as tecnologias mais apropriadas para o problema em questão, e que melhor se adequem ao cenário da organização.

Uma definição de Arquitetura

The Rational Unified Process An IntroductionOlá Pessoal!

Neste post gostaria de compartilhar um trecho do livro “The Rational Unified Process: An Introduction (3rd Edition)” de Philippe Kruchten, disponível no capítulo 5 (An Architecture-Centric Process), página 84. O texto fala sobre uma definição de Arquitetura, que é um tema bastante pertinente, diante das várias abordagens e interpretações existentes no mercado para o escopo de atuação de uma área de arquitetura ou de um arquiteto.

Basicamente o texto fala que arquitetura presa pela estrutura de um sistema, sua decomposição em elementos, subsistemas e suas interfaces, juntamente com comportamento e colaboração entre elementos. Requisitos não funcionais (ou atributos de qualidade) também fazem parte da lista de itens que a arquitetura de um sistema deve contemplar, como por exemplo, performance, reuso, escalabilidade, resiliência, etc. Outro ponto importante mencionado é que arquitetura engloba não apenas aspectos técnicos, mas também econômicos e sociológicos. Podemos entender como aspectos econômicos os recursos e limite de orçamento disponível em um projeto. Por sociológicos, as pessoas envolvidas e como a arquitetura do sistema pode os afetar, sejam eles desenvolvedores, designers, gerentes de projetos, ou mesmo usuários.

Confira o trecho a seguir.

Many definitions of architecture have been proposed. The Rational Unified Process defines architecture as follows.

Architecture encompasses significant decisions about the following:

  • The organization of a software system
  • The selection of structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaboration among these elements
  • The composition of these elements into progressively larger subsystems
  • The architectural style that guides this organization, these elements and their interfaces, their collaborations, and their composition

Software architecture is concerned with not only structure and behavior but also context: usage, functionality, performance, resilience, reuse, comprehensibility, economic and technological constraints and trade-offs, and aesthetics.

This definition is long, but it attempts to capture the richness, the complexity, and the multiple dimensions of the concept. We can elaborate on some of the points.

Architecture is part of design: it is about making decisions about how the system will be built. But it is not all of the design. It stops at the major elements—the elements that have a pervasive and long-lasting effect on the qualities of the system, namely, its evolvability and its performance.

Architecture is about structure and about organization, but it is not limited to structure. It also deals with behavior: what happens at the joints, at the seams, and across the interfaces.

Architecture not only looks inward but also looks at the “fit” of the system in two contexts: the operational context (its end users) and the development context (the organization that develops the system). And it encompasses not only a system’s technical aspects but also its economic and sociological aspects.

Architecture also addresses “soft” issues such as style and aesthetics. Can an architecture be pleasing? Yes, to the educated eye it can be. Issues of aesthetics have their place in making a design uniform, easy to understand, and easy to evolve, with minimal surprises for the designers.

Arquitetos devem saber programar o seu design

97ThingsOlá pessoal!

No meu primeiro post neste blog eu falei sobre um capítulo do livro “97 Things Every Software Architect Should Know”. O capítulo tratava de um comportamento bastante comum e, no entanto, bastante repugnável, a arrogância. Neste post eu falo sobre três capítulos deste mesmo livro, porém, desta vez o tema é relacionado às habilidades de programação de um arquiteto.

O livro citado é composto por diversos capítulos curtos, onde cada um deles traz conselhos e experiências de diversos arquitetos renomados, de diversos lugares do mundo. A ideia geral do livro é que cada capítulo trate de um assunto distinto, formando assim um conjunto de coisas distintas que todos nós deveríamos saber. No entanto, notei que três capítulos deste livro tratam de um mesmo tema, denotando a sua importância. Veremos então a seguir a ideia geral dos três capítulos e também algumas passagens.

Architects Must Be Hands On – página 38 – John Davies

Neste capítulo, John Davies diz que um arquiteto deve ser capaz de preencher qualquer posição em um time, desde o cabeamento de rede, até a configuração do processo de compilação e a execução de testes unitários, por exemplo. Para enfatizar, ele ainda diz: “Without a good understanding of the full range of technology, an architect is little more than a project manager”. Ele diz ainda que os desenvolvedores devem ver um arquiteto como um líder, capaz de dar exemplos que possam ajuda-los a se desenvolver. Arquitetos que não possuam conhecimento sobre uma determinada tecnologia empregada em um projeto não podem esperar que os desenvolvedores tenham confiança nele.

Before Anything, an Architect Is a Developer – página 126 – Mike Brown

Neste capítulo Mike Brown faz uma associação entre a carreira de um arquiteto e outras carreiras de outras áreas, porém, que requerem o mesmo nível de senioridade. Ele diz, por exemplo, que nenhum juiz nunca foi um advogado e que nenhum chefe de cirurgia nunca foi um cirurgião. Ele diz ainda que as pessoas que ocupam estas posições devem continuar a se atualizar e a se desenvolver em suas respectivas áreas. Isso não é diferente para nós arquitetos. Outro ponto bastante interessante colocado pelo Mike é que o código de um arquiteto é a sua moeda, sendo esta a forma mais eficiente para ganhar a confiança dos desenvolvedores. E para finalizar, Mike ainda diz: “Part of knowing what is feasible in a solution is having knowledge of the effort involved in developing the elements of the solution".

If You Design It, You Should Be Able to Code It – página 150 – Mike Brown

Neste capítulo Mike Brown diz que é muito tentador para nós arquitetos criarmos designs bem elaborados e abstrações que endereçam os problemas de forma bastante elegante. Ele diz ainda que é ainda mais tentador experimentar novas tecnologias em um determinado projeto. Porém, Mike diz que temos que pensar que no dia-a-dia, quem implementará o que ele chama de acrobacias arquiteturais, são os desenvolvedores e que isso normalmente traz impacto para o projeto. Mike ainda aconselha:

“Don’t use a pattern in your design that you haven’t personally implemented before. Don’t rely on a framework that you haven’t coded against before. Don’t use a server that you haven’t configured before. If your architecture depends on design elements that you haven’t personally used, there are a number of negative side effects:

  • You will not have experienced the learning curve that your developers will have to face;
  • You will not know the pitfalls to avoid when using the elements;
  • You will lose the confidence of your developers;
  • You will introduce unecessary risk.”

Arrogância e outros erros comuns que nós arquitetos podemos cometer

Olá pessoal!

Segue abaixo um texto bastante interessante que é parte do livro “97 Things every software architect should know”. O texto fala sobre arrogância e alguns erros que nós podemos cometer no dia-a-dia. O livro é uma composição de experiências de diversos arquitetos renomados do mundo inteiro. Eu recomendo!

97 things every software architect should know

There is no “I” in architecture

Dave Quick – 97 Things every software architect should know.

I know there really is an “I” in architecture. But it’s a capital “I”, calling attention to itself, dominating discussion. The lowercase character fits nearly within the word. It’s there only because it fulfills requirements for proper spelling and pronunciation.

 How does that relate to us as software architects? Our egos can be our own worst enemy. Who hasn’t experienced architects who:

  • think they understand the requirements better than the customers;
  • view developers as resources hired to implement their ideas, or;
  • get defensive when their ideas are challenged or ignore the ideas of others?

 I suspect any experienced architect has fallen into at least one of these traps at some point. I’ve fallen into all of them and learned painful from my mistakes.

 Why does this happen?

 We’ve had success. Success and experience build self-confidence and allow us to become architects. Success leads to bigger projects. There is a fine line between self-confidence and arrogance. At some point the project is bigger than our personal ability. Arrogance sneaks in when we cross that line but don’t know it yet.

  • People respect us. Tough design questions provide a critical safety net. Our own defensiveness, arrogance, or emphasis on our experience can result in missed design questions.
  • We’re human. Architects pour themselves into each design. Criticism of your creation feels like criticism of you. Defensiveness is easy. Learning to stop it is hard. Pride in our accomplishments is easy. Recognizing our limitations without conscious effort is hard.

 How do we avoid it?

  • Requirements don’t lie. With correct, complete requirements, any architecture that meets them is good one. Work closely with the costumer to make sure you both understand the business value each requirement provides. You don’t drive the architecture, the requirements do. You do your best to serve their needs.
  • Focus on team. These are not just resources; they are your design collaborators and your safety net. People who fell unappreciated usually make a poor safety net. It’s the teams’ architecture, not yours alone. You provide guidance but everyone does the heavy lifting together. You need their help as much or more than they need yours.
  • Check your work. The model is not the architecture. It is only your understanding of how the architecture should work. Work with your team to identify tests that demonstrate how the project’s architecture supports each requirement.
  • Watch yourself. Most of us fight our natural tendencies to defend our work, focus on our selfish interests, and see ourselves as the smartest person in the room. Pressure pushes these tendencies to the surface. Consider your interactions for a few minutes every day. Did you give everyone’s ideas the respect and acknowledgement they deserved? Did you react negatively to well-meaning input? Do you really understand why someone disagreed with your approach?

Removing the “I” from the architecture doesn’t guarantee success. It just removes a common source of failure that’s entirely your fault.