7 Tips to Improve your Project Solution Architecture Outcome

on Wednesday, 23 October 2013. Posted in Enterprise Software , Solution & Business Architecture, Blog

7 Tips to Improve your Project Solution Architecture Outcome

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

the architecture

*        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.

 

***Documentation

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.

 

 

Comments (10)

  • Tyler Robinson

    Tyler Robinson

    23 October 2013 at 19:15 |
    Great post! Will start using Tip #1, Just survived a condescending experience with an ERP architect that handed us down specs
    and told us to figure it all out. Ivory Tower complex!
  • David Miller

    David Miller

    23 October 2013 at 19:34 |
    Excellent post, I agree with you wholeheartedly. For projects to succeed there must be a partnership and keep the politics to a minimum.
    • Tina Kaltsis

      Tina Kaltsis

      23 October 2013 at 21:22 |
      I would have to agree with David especially about the politics! Excellent post Alex
  • Steven Hernandez

    Steven Hernandez

    23 October 2013 at 19:58 |
    First time to your site, got here from Linkedin, You make many good points in the article. One that underlies many of them is
    that to be effective, developers and architects should understand the roles they are playing and cooperate to get the job done. Developers need to understand that someone needs to look across many projects and make choices that are good for the group but not necessarily for a particular project.And architects should listen well to your warnings, avoiding preaching, leading by example, keeping humble, treating their job as engineering, and ensuring the viability of their proposals.
  • Vinh Lam Sam

    Vinh Lam Sam

    23 October 2013 at 21:03 |
    I also prefer working with diagrams, text can be misinterpreted, your article is so right on, they just stopped my project main reason we had people playing the political-power game and the VP's were smart enough to see the toxic alignments between each teams (dev vs arch), we were spending millions with no progress , I think main issue everyone looking at their own interest only and being a contrarian for no logical reason.
  • John Briggs

    John Briggs

    24 October 2013 at 00:07 |
    Another excellent post, I am a reader of your blog for the past 3 years and the information you post sharing your experiences and knowledge is great, hats off!
  • Lisa Wu

    Lisa Wu

    24 October 2013 at 15:20 |
    I agree with your points, live this everyday in my job, I am a junior architect starting and realizing quickly to deliver a project architecture not as easy as development where things are more tangible and you don't have to worry about human nature. Bookmarked the site!
  • Rabi Patel

    Rabi Patel

    24 October 2013 at 18:43 |
    Great article, I wish some people in my company read this, it is an issue at our company were clans have been built similar to the ipad game clash of clans that make collaboration somehow difficult.
  • Michael Androssoff

    Michael Androssoff

    25 October 2013 at 07:24 |
    Alex ,great website, love this article (live this on a daily basis) I enjoy how you express your thoughts and opinions and make it into a 2 way conversation with others around the world.
  • David Li

    David Li

    27 October 2013 at 09:45 |
    I am an sql developper working in a COE, i agree with your article and comments, at our company , we hired allot of gods gift to mankind individuals that makes the situation hard to work with. That has made me just to do my job and not care anymore just to get my paycheck. Politics rules in our company, intelligence and knowledge is second hand. good site.

Copyright 2014 Appsconsultant.com. All rights reserved.