How to be an Effective, Pragmatic and Business Value Focused Solution Architect
In a fast changing and disruptive business environment, becoming an effective Solution Architect can be challenging. The following are some key points that make an effective, pragmatic and a business value focused Solution Architect, who can make a difference to a business.
Avoid Perfection – One thing I frequently say to people is that I am not a purist architect. I do not try to preserve architecture purity or perfection at the cost of business value. A timely and pragmatic solution that can add business value is more valuable than a perfect IT solution. This is where business value based architecture decisions should be made to maximise the business ROI. However, this does not mean the solution is poorly designed. You will still need to assess best practices and patterns that weigh up the risks associated with the decisions you make. If there is any architecture debt to the enterprise, understand and articulate this to the relevant stakeholders and officially record this as an architecture debt. Ideally, you want to outline what the debt means to the organisation and define the cost and timeline to correct it.
Architecting for Agility – The nature of business today can be volatile and change can be rapid and frequent. A business may need to adapt to its competitors, changes in regulations or a changing political landscape very quickly to stay relevant and be competitive within a short period. Therefore, the IT solutions we architect to support business functions should have this as a default founding principal. We need to develop decoupled solutions which give the business the ability to change and adapt quickly. In most cases, this will come at a cost and the architect will need to justify this to their stakeholders and make the appropriate decisions relevant to maximise the business benefit.
From a strategic perspective, I still believe businesses need the long term planning and vision. The rapidly changing market place and industry disruptions are making this extremely difficult. I am seeing more companies these days where they cannot define their next 12-18 months, let alone a 5 year business and technology plan. Therefore, where technology is fundamentally disrupting everything we do today, your IT solutions need to be architected with agility in mind.
Just Enough Documentation – I am a big believer in the ‘Just Enough [anything you want]’ philosophy and this applies to the documentation a Solution Architect produces. I have seen many occasions where highly detailed hundred paged Solution Architecture Documents (SAD’s) barely getting a first glance by the relevant people. Many people are time poor and just don’t have time to read through pages and pages of text to understand a solution. The purpose of the SAD it to clearly describe the solution to the enterprise architects for endorsement as well as setting the direction for the detailed designers or technical architects to define the next layers of detail. Therefore, if we can produce clear architecture diagrams, document all relevant architecture decisions along with any other relevant and concise details for all parties, we do not need to create a large number of documents which adds no real value.
Keep It Simple – There are many solutions being designed to be overly complex for no valid reason, apart from the architect simply trying to showcase their skills and capabilities. For example, there is no reason to design a solution with multiple levels of redundancy when the actual business use case does not warrant a high availability solution. When the customer needs a hammer, you don’t need to provide a sledgehammer. The Solution Architect should design the solution with the actual use cases and requirements in mind to develop an appropriate and pragmatic solution. A complex solution is not necessarily a good solution, and sometimes it takes considerable effort and ingenuity to design a simple yet elegant solution rather than a complex one. Complexity should be introduced only when you have to and the reasons for introducing the complexity stacks up against the business value.
Be Confident, Own your Solution and Don’t be Afraid to Make Decisions – I have come across architects who are not confident and are afraid to make solution architecture decisions. Some would rely on enterprise architects to do this on their behalf or get the business stakeholders or projects managers to make the final call.
If you are the Solution Architect on a project or program, then you are responsible for how the solution is architected to ensure the business objectives and goals are met. Therefore, be confident, back yourself and make the decisions to drive a good business outcome. Document the reasoning on why you have made certain decisions as a reference, and do not be afraid to make final solution architecture decisions as this is your role and purpose. On most occasions, particularly consulting architects, the business is trusting you with developing IT solutions that can cost millions of dollars and expect you to solve complex business problems for the organisation. You need to be confident and trust yourself in order for the business or client to trust in you and your solution.
I hope you agree with the discussion above and please let me know via comments about what you think might be other key points on becoming an effective Solution Architect in the current climate can be.
