The goal of architecture is to identify the requirements that affect the structure of the application and design a business solution.
A well thought-out architecture should always consider these important principles:
• Build to change instead of build to last
• Understand the end user needs and the domain before designing components
• Identify sub-systems in your product and consider layers and components to abstract them and identify the key interfaces
• Use an incremental and iterative approach to designing the architecture
• Learn from company history, document your decisions and identify and mitigate key risks
But as we all know: every organization has its share of political drama: personalities clash, diverging agendas. Having worked at many companies here are some thoughts and tips to avoid architecture delays or having your project stopped:
*** Communicate like you are a Teacher, not a Preacher
A general assumption, architects are supposed to share their knowledge and experience. Failing to share that information is pretty much against the job description. But how you communicate that experience is the most important part of the job. Think of your best teachers in school—did they ever go in front of the classroom and tell you how smart they were? I don’t think so. They found subtle ways to express their knowledge that encouraged learning and asking questions.
Tip #1 that I often use , I start my sentences with ‘I think’ this will open discussion items and questions and encourage a two-way discussion.
Tip #2 Architects are usually quite smart and have a breadth of knowledge but the tone, quality and delivery of the Information is more important than the content, try to always communicate like a teacher .
*** Standards apply to Architects, Developers and COE (Center of Excellence)– Don’t take the easy path take the smart path
Enterprise architects put together standards documents that lay out , architecture patterns, coding conventions, infrastructure, source code nomenclature, and build structures. But to publish those standardsand fail to hold yourself to them is the highest form of hypocrisy. If you can’t follow a standard, why would you expect anyoneelse to follow it too?
An example, a company wanted to perform a point (system)to point (system) development, in this case standards existed to use web services with these systems, the development team took a quick decision and coded the point to point development and satisfied the business requirement. The director of the COE (Center of Excellence) did not realize an impact existed onto a surrounding system , the issue caused a security and reconciliation issue. In this case the cost to fix the data & interface was 4 times the initial budget.
Tip #3 : By applying the standards to your work, you’re respecting the standards of the organization; you also see what will be painful for other groups. Respect your standards and reduce the power politics within your organization.
Tip #4 : Always try to eliminate 'it’s not my job” attitudes at your workplace, especially when you have the role of the architect.
***Command from the dugouts, not from the Ivory Tower
Not once, in any company I’ve ever worked with or for, did this idea bear positive fruit for the development teams involved. Instead, these segregated groups architecture and development teams have generated one or more of the following:
* Contempt for the architecture because the developers had no say in
* Rejection of the framework because it was impractical to apply to
the project at hand
* Blatant disregard for the standards set by architects because the architects did not have to respect company deadlines as a result of the delays introduced by their work
Tip # 5: Architects should be a member of the project team, never as a visiting diplomat to the team. Teams respect the opinion of someone who lives their daily reality side-by-side with them, not someone who hands them the Ten Commandments.
*** Architecture teams that believe their involvement is limited to the design phase don’t really understand what it means to be an architect
An example, when a building is being built, the architect is on site during the majority of the project, overseeing the effort at a high level, ensuring that little changes are not impacting the big picture. All the while, the architect assists in solving problems that arise from his or her design from a practical standpoint, same as any enterprise software deployment
In short, the architect’s involvement is continuous, not disconnected.
Tip #6 : Make sure the architect is involved in the design, build and deployment phase.
Tip #7 : Always begin your intervention with a contextual diagram and perform a walk through with the team, don’t write too much text it may cause confusion at the beginning. Developers and implementers interact better with diagrams.
For architecture projects to succeed there must be a partnership of developers,implementers and architects. Successful partnerships require two way communication and trust, none of which happens when someone acts like God’s gift to mankind, insists on his way or the highway and doesn’t actively get his hands dirty.
Feel free to share your tips , comments and thoughts.