2 February – revised 25th July 2022

IT Solutions Architecture

Over the years I was in the role of IT Solutions Architect, (SA). I would be asked how to do SA. Well, it is not that simple. The role is peer approved, even by international reviewers and has no formal exam or certification process. It is in effect a build up of prior experience and qualifications. It is part of a roadmap.

This can irritate others. Some wanted me to have their qualifications, to follow the same processes they did. Some would not accept the industry standards and value of the role and thereby demote it. We know that a train driver has a certain psychology. Attempts have shown that one cannot put people with Masters degrees into the driver’s cabin. It does not work.

You may love the beauty of mountains and streams while I have loved the beauty of computer Hex code.

To me the SA role was quite natural. Now I understand in a better way the types of people we employ in the workforce. While the SA role can be highly technical, and it does vary between organisations, including levels of authority and project control, the role reduces risk and provides workable solutions – which saves money. Which protects from penalties. Which …

The role has a creative and intuitive aspect. Entrepreneurs are creative. Economists may put these ideas into a working product. We may suggest an accountant is conscientious (conservative) while an architect is creative – to give some distinction and recognition of the necessary existence of both.

Let us put aside the definitions for the moment. Imagine that early in your career you do a lot of software programming, understanding how people interact with software. You can tell what is natural to a person versus awkward. If you never know that, how can you program it into your detailed solutions? If you do know it, you can see the problems people create. Is there any way to teach this let alone advise others on what to do, or not to do? Sometimes we can, and sometimes we are not in a position to do that.

The same applies for best practices, robust solutions, integrity of data and so on. A number of people only view the world with a narrow and determined definition or focus. The SA is used to broader aspects and therefore brings into play skills to help facilitate other people’s own independence and value, yet at the same time, best outcomes for themselves, teams, stakeholders and projects. This can clearly mean challenges, and even a natural bent towards psychology.

Some SA’s will not work this way, rather instruct. It depends on the organisation. I have worked with both styles and know which I found destructive to the soul, or flourishing.

So, I say the key is to facilitate, but where necessary to insist – as things have to hold together when someone is pulling apart, either knowingly or not. When we compose a solution, people love it, they jump on board, they excel, they develop, they expand, they produce with great confidence and assurance. There are always those who are grumpy, but the best projects are quite energetic and easy by comparison to having those types of people.

I once arranged a community event. It had a huge marquee, jazz musicians, food etc. We had to look at many logistics and incorporate safety, handling of money, security, third parties and so on. Once the vision was presented, everyone just worked – because they wanted to. Good IT projects are the same.

At times, people want solutions but may be stuck. They may have ideas but cannot express them. We learn to help people say things rather than thinking they are silly. We say what is on their mind. In this sense we become normal people no matter who we are – shop floor operator or CEO. These things can turn out to be critical. We look to remove project gaps, lack of information, or to ensure we do not create future problems in the solution. If you are focused on a specific part of a project you may not realise the way your work impacts others, or how other people’s work impacts yours. The SA needs to see these things, actively, continually. There is a broader umbrella.

On the whole we represent the interests of all parties.

On one project, a pending penalty was looming ahead. The sky was dark. The storm was approaching. After looking at the business, gathering some data, thinking about the problem, talking to people, I humbly said in a key meeting, what do you all think if we did something like this… We could do this… We could do that…

People were so relieved. The project manager called head office, said we have a solution and what it was. People pulled together because now they believed in various ideas they had already had, and with the SA behind the project, they had the confidence. And people developed aspects I had not thought of. The storm no longer threatened us. We had clear skies.

Or did we?

The problem was, we had to work with what we had in the narrow time frame. Due to this, extra workload was placed on staff. The project therefore had to be split into two phases. If the second phase was not executed, people would hurt in the long term. I made this very clear. It was a lot of work and a lengthy process to move into phase 2. As people did hurt to some degree from the extra workloads, the solution was critisiced on the shop floor. All I could do was describe what we built, why we did, the looming penalties, and the relief we would have from Phase 2. The penalties would have been $100,000 per month.

All committed people expend their energy, whether creative or conservative. An end-to-end solution is a combined effort.

Such demands are not as “prolific” for day-to-day websites – of course. However, we can still follow principles that we develop with solutions in mind rather than web pages with bits of data thrown onto them. For example, we keep our clients up to date, we make sure we bear the load so they do not have to worry. We send out emails to clarify what we have agreed on, and task lists for both of us. We maintain a positive and healthy assertive approach. We look at the business and real goals verses perceived goals. DO we give what people need in an easy way? Are we composing and telling a story?

What, for example, is the point of having a beautiful website if the home page takes too long to display? What is the point of having a website if the host provider’s data backups are not disaster recovery backups and we lose the site? All such things are part of a solution’s concerns that we address in some degree. Formal company projects address these things in great detail.

Part of the SA environment is highly technical, but it is also a role of much more freedom than many employees experience. This can cause someone to be adverse, thinking that you think you are special, or big noting yourself. True adversity in the workplace always shows up with bad behaviour, such as bullying, yelling, lack of care, bragging, pretense and so on.

I always talked with the shop floor operator with as much genuine concern and interaction as with a CEO. There may be different dynamics and awareness at play. Shop floor banter is different to the way a technical manager may be. And how do we engage with someone who is proud or controlling? There are many examples. Some clients are not suited to their jobs which causes other project problems. We engage with people.

In my overseas Taipei project, people overworked to no benefit. I had to insist on a coffee break, so I left the building. What I did not appreciate was being tested, to see if I knew my job. It is a bit of a story. Technical details were withheld from me so I told them what made no sense and what the problem had to be. That is when they said I knew what I was doing. They also asked me to provide an immediate out-of-scope solution to their geographic IT infrastructure while I attended a meeting, using school yard behaviour while they goated me. So I gave them a real solution on the spot. But that is not how we work. This company received our other in-scope solution. I also gave them observations where their Outsourcer was not telling the truth, even telling them what to do instead of the other way around. I showed where they lacked some process and documentation. We were being used – there is no question on this. The incumbent received the contract. This is all good SA experience. Despite these things, and immensely enjoying the people (and food) in Taiwan, there is always a sense of the SA holding projects and people together, which is of great comfort with complex projects and customers. However, something in me was very desirous and strongly pleased as soon as the aircraft wheels lifted off the tarmac.

Projects do involve culture, at a higher level such as a country, or with teams that may have grown up with a particular culture. For example, I work by transparency, but some groups hide their work. I am open to putting previous ideas aside, but some people cannot let go. We not only see these things in action, but we detect it in the way people respond, even their tone of voice or body language. In one meeting I knew full well who was second to the CEO, and that was based on verification of the body language. When we work with another country there are rules. We are readily seen as arrogant and rude if we do certain things that for Australians are quite normal. There is no book that teaches us these things. As a simple example, there is a particular way we work with employees in Japan. There are rules about what we do not say to an employee from China or to an employee from America.

I think our SA work grows in steps, appreciating previous project experiences. The best architect team I met were from the ANZ bank in Melbourne. But prior to that I had worked in Perth with Bankwest. My manager used to say to me not to worry, but just do what I do, as it works. And so it did. That prior work to ANZ was vital. I have worked with very large companies and projects. ANZ involved every department of their business, creating a solution with modelling as a high level blueprint, while the competitor simply produced brochures for bits and pieces – not a solution across all departments. My confidence and skills were based not only from my own initiatives and work, but the mentoring and help of those around me over many years as I clocked off one project after another. (When you receive good training, or have access to resources, you know it thereafter. I even had good advise on one project from Amex, which I never forgot.) Therefore, a single person is just as important to me as a company. There was only one time I could not viably manage a project as a sole SA (as compared to a team of SA’s). Interestingly the client was destructive and I retracted myself from the project. We have to look after ourselves and sometimes in the corporate world that has consequences. There are times a sales force may engage a project to lose money in order to make it in the longer-term, where people are not treated as people. These bad projects will have components that fall apart at some point for a number of reasons.

It is always possible for a company to set boundaries and rules, but this may not be part of the culture. Bad practice leads to further bad practice or even illegalities. To maintain a good view, we develop perceptions. If I think my company is given priority over another during a crisis, I may believe that, even if it is a lie, only to find out during a real crisis, there is an insurance policy to cover that lie. Like it or not, the SA has rewards and benefits by being able to talk to all manner of people, but we also learn more about what happens behind the scenes, how people act responsibly or unethically.

Our skills and awareness lets us construct solutions that flow. There was once a shift from a particular old technology that needed an interim approach so that aircraft in Melbourne could continue their maintenance. I gave the only technical solution available at the time. It worked. A senior engineer was, I think, abusive telling me it would not work, despite my research and validation. We will come across resistance at times without an apology after the fact. I have never had one failed project, or one failed disaster recovery of a system. We understand what technology does. We search for what works even if outside the box.

One financial project wanted to use the spare space on the back of customer statements to print advertisements. Quite a long story, but over time I developed the algorithms which were later programmed into code. As a solution, we ensured we only worked with what we felt was a reasonable scope, meaning the work would be manageable and not introduce risk. I even kept a notebook beside my bed at night so I could draw diagrams and test algorithms. The final algorithms fell into place on smaller sheets of paper when I was at the airport waiting for my flight.

On another project we moved legacy data to a new system that had experts in USA do reverse engineering. The proof of concepts were reliable. The project management team gave an instruction to make the project a shorter timeline. The overall project would not be able to meet the timeline, and my particular solution came under fire. There was a lot of active communications to try to keep the project going despite raised voices and threats. I knew an earlier alternative proposition technically could not work. Fortunately the project (as expected) did not meet the timeline so management had to deal with that. My project was therefore completed as intended.

I was once on a phone call during a meeting where the project manager swore at the client using four letter words, telling them how stupid they were. Of course I was surprised. That person left the company and I picked up the pieces. This involved changing the design, working closely with the client, and apologising for what had previously happened to them. All part of the job.

There was one project that involved data affecting all Australians. I had previously suggested an idea to the company but was told while nice, it would not need to happen. Technology changed and I believe that is one reason why the company eventually faced technology losses. There may have been a different agenda for the company stakeholders. I have only ever seen technology change, but in measure. For instance, a particular technology may change every three years. Some changes take fifty years but change they will. Some technology may change over ten years – it depends. I recall seeing the technology from the 1980’s and understanding it was dead technology. Back to the story… a new project came up that was pushed from USA sales reps. It was a bad project, but people wanted to make money. I knew it would have serious issues. If we wanted to really run with it, it would cost a lot more. This and other projects did at times have their costings slashed to make them look okay. We would need to have industry changes across all financial institutions. It would be possible, and actually, amazing. I developed the solution and in private was commended for that work. However, a government business won the project and I knew it would be a mess as their corner of the market was not broad enough. And so it struggled till several years later it was withdrawn. No surprise, and no one won. This is how the SA thinks, in my view.

But would my solution have worked? It would have had more impact and could potentially grow, but in my view, it grated. What was wrong? It really needed two organisations to come together, respecting that richness. It also needed a broader, more monumental vision. Usually I find limitations around me, and often people do not have inner vision or confidence to handle what is larger than themselves, or to make decisions. Not that this is wrong – it is just how it is. If we can respect what is happening, we can work better. How many projects have been forced on people only to fall apart? The true solutions architect role is to remove these issues – if the company allows it.

What can I say? If you want to ignore your architects, you will suffer for it. A creative and competent solutions architect mixes creativity and practicality with good people in a way that uplifts us all. In that sense no one is lifted up above another.