Through the lens: An architect in the computing world – Five principles

Architect – a person who designs and in many cases supervises the construction/delivery of their design, usually based on the requirements of a customer

I have always wondered what is required to be an architect. While technical and functional skillset is the base for any architect, there must be a few other guiding principles that can help an architect to deliver what the customer wants. Today, there are many who have sound technical knowledge, have the best domain expertise, have an excellent skillset in articulation, and have great interpersonal skills. But very few can give the customer, what they want.

Yes, the customer is king, but an architect has to deliver the best possible solution for the customer based on the customer’s pre-set parameters.

So, it’s more of we deliver what the customer wants, but in a way that we believe is the best. While our expertise may lead us to design something we feel the best (and be reluctant to accommodate a customer’s request), always remember that the customer pays!. Dollar bills!. You see, there is a middle ground – Deliver the best but/and make sure the customer is happy.

One of my recent involvements, made me rethink the non-technical, non-functional qualities an architect needs. These are definitely not interpersonal skills, So I will leave it to the reader to classify them. I think these are general guidelines that any project or any architect usually follows, so maybe it can act as a recap or reminder to all of us – architects. These are my five principles, I’m sure everyone may not agree to it, but here you go!

1. Show them what you do

On a high level for an enterprise-wide project, these are the phases involved. – Discovery, Solution Modelling, Build, Test, Go-Live. While each of the phases has its own deliverable to mark the completion of the phase, the time they take is usually high.

Imagine that you are building a house and spending millions of dollars. Won’t you expect to see the progress of the house every now and then? Will you accept your engineer/architect/contractor to just give you weekly info on what they did? I won’t. I will want to see what they have done for each week.

A customer who pays for the solution they need will need to see what has been done periodically.

Note the emphasis on ‘See’.

As part of the build and test phase, you can obviously show the solution that is being built (Classroom Pilots / Demos, etc.,), but what will you do in the lengthy discovery or solution modeling phases (apart from the final design or blueprints given at the end of the phase)? Believe me, capturing/elaborating requirements in a tool like Jira or ADO is a minimum activity now. Large / Multi-national enterprises, usually have all their requirements well written with their own Business Analysts / Users. So what else we can do to act as a differentiator?.

1. Minutes: Let’s start with the basics – Send ‘Minutes’ for your meetings and time spent.
   • MoM as we usually refer needs this basic information – Topics Covered, Participants, Discussion Minutes, Decisions Taken, and Finally Next Actions with appropriate ETAs/ Follow-Up dates
2. Present what you understood: (Ah yes, Whiteboarding) How about a simple diagram, an algorithm, a flowchart, an architecture, a PowerPoint smart art, or a simple cross-functional diagram?
   • Having a lengthy discussion on the customer’s process needs a definite output and it has to be immediate/quick. MoM will be a mandatory output, but your differentiator is going to be a pictorial representation of what was discussed.
   • I usually prefer putting together diagrams / writing down algorithms during the discussion with my screen shared (or on a whiteboard if it’s an in-person discussion). (Recently a friend shared with me a neat trick to create sequence diagrams with UML. I’m a fan of that now). This helps me with the below
     • Saves Time (Yes, a lot!!). I can just reuse this for my MoM or even in future deliverables
     • Helps me not to forget the nitty gritty.
     • Gives a chance for the customer to validate our understanding on-the-spot
     • Finally, it gives a minor satisfaction to the customer that we are making sense of their process!

Tools I use – OneNote (A big fan), Notepad, Any online UML Sequence Diagram, PowerPoint, Visio.

2. Stop selling, start delivering

This typically applies to the delivery phase. Yes, as the phase name suggests, we need to deliver.

The customer has spent millions of dollars to choose a product, get licenses, and then onboard an SI / ISV to implement it for them. Do you think they will be ready to spend more to buy a few more new products/ideas? They seldom do. Usually, their first priority is to see the fruits of their current labor. Maybe after the initial release, they will be ready to go overboard. I have seen customers visibly upset whenever an architect discusses with them a design that needs additional cost via customization, licensing, or products.

• When should you sell? – Stick to the pre-implementation (RFP, RFI) phase. You can stretch a bit of selling to the discovery phase as well. You can definitely sell after the first go-live or MVP, as the customer would have already seen the benefits of their investment and will be ready to invest more or shall I say, trust you better!.
• How to design without selling? – You have procured the project based on some assumptions which include cost, effort, timeline, and resourcing. Sticking to this boundary, deliver a solution that can meet the customer’s requirements. If the customer’s requirements cannot be met within your boundary, tell them what is possible based on what has been agreed. This heavily depends on the ‘Scope of Work’. If the ‘SoW’ is not clear, you will need to depend on the effort estimates and go back to your management for support.
  • I believe it is right to tell the customer (read as customer’s project manager) from the start of the solution modeling phase, what is possible within the budget. Yes, they will be irritated with our pushback, but it also helps them understand that we have a boundary. Explain to them the boundary, I have seen many client managers understand this pretty well. (Also, the third principle can help here) Remember, we are not here to sell, we are here to deliver. Selling was done before we got the project.
• But the solution will benefit from this additional customization and cost, should I not focus on the best solution? Yes, you should focus on the best solution. and hence my third principle!

3. Options, options, options

For any problem, there can be more than one solution.

Always make sure to give multiple options, at least for the complex problems/requirements.

While giving multiple options, make sure to differentiate on these categories as a minimum – Technical Benefits, User Experience, User Interface, Timelines, Maintenace, and finally cost. Make sure to mention your recommended option for the best solution.

Of course, many of the industry veterans I know, have always suggested going with the single best solution. I think that will work when you are submitting your solution for a proposal, to show your proficiency. But during delivery, you will need to give options (and yes a recommended option among them).

Giving multiple options for a complex requirement will give the below benefits

• Customer satisfaction – Customer values the effort you have spent to help them decide and build the best possible solution. I have seen many customers personally appreciate providing them with multiple options. It works.
• Highlighting the effort and cost involved – Yes, you can show the customer which option will fit within your boundaries and which options will need additional effort or cost. This is a polite/professional way of saying what you can do and what you cannot. If the customer is ready for costly options, they will definitely choose.
• Future Roadmap – You can help the customer define their future roadmap. At the moment, the customer might have a budget only for option 1, but at a future date, they might go for option 2, so your current work can help them to decide the next steps.
• Knowledge is Power – Yes, giving multiple solutions for problems, helps you as well as you usually do some R&D / PoC to get the required information.

4. Own the solution

Owning the solution and delivering it – This is very important for an architect. I have seen many architects who blame the developers/development team for an incorrect / issue-prone solution or delivery. While your role might not have this responsibility in your organization (certain organizations don’t, as they will have a separate development/delivery team), this is required for building an effective solution for the customer. The customer will start trusting you for the next project, only if you deliver what you promised.

• I don’t have the development under my control/purview, so how can I own the solution? – Work in partnership with the DEV Team / Lead. Try to be in their shoes, as they do the bulk of the heavy lifting for the solution. Understand the effort estimates and stick to the SoW. If you are deviating from the SoW or estimate, make sure your team understands the need for it (The data you prepared for 3rd principle can help here as well). Don’t commit to short timelines or complex designs without their buy-in.
• My design is based on my experience, and the team fails to understand – Tricky situation that happens in all projects – You have 2 ways: Make them do a PoC to make them understand your point. You can also, if possible, get both solutions developed (of course time/effort wasted) or you should advise them that you will take responsibility for the solution. Yes, I agree, this is a slightly difficult topic that will need better interpersonal skills to manage.

5. Being Neutral (or can we say Integrity?)

A 60-year-old client manager once told me that the important quality they expect in an architect or an SI partner representing an SI / ISV is to give the best solutions regardless of whether it will bring additional business to the SI or additional licenses to their product.

I believe him.

However, it is always better to be neutral. We, architects, are here to deliver the best possible solution for the customer within the boundaries specified to us by both the customer and the organization we work for. We can’t go overboard and that is where principle 2 helps.

• My organization is expecting more revenue, I can’t do that by being Neutral or by practicing integrity You can do both at the same time. Read principle 3.
• My customer is expecting more than the effort or cost estimated or SoW. Read principle 2(which also refers to principle 3).

I believe these five principles will help any budding architect or a functional consultant.

Well, here we are at the end of my post. This is my view based on my experience. Do comment on your thoughts/ideas. Happy architecting.

Cheers.