IT Solutions Architecture
For several years I was in the role of IT Solutions Architect – SA. At times people asked what an SA is, or how to do SA.
Looking back, I notice that the industry has different focus on the role. IBM GSA is quite different to ANZ Bank, as to Optus – as an example. I prefer the style from the Bank.
If the SA controls a project and its technical documentation and delivery, this will be highly detailed work. If a solution still has detail but facilitates others, I think we have a healthier environment and better projects.
What I liked about ANZ was the way the team was both dedicated and working together, having several people in the team with a senior Architect.
I have personally questioned some companies using the title of SA but not really grasping or perhaps respecting what the role is. Was the SA doing solutions work?
The whole idea of SA is to both create IT solutions and to save money from failed projects, and it works. This does not mean a company will not have roadblocks or cause their own failures. We only have who we have, and this can include a whole era of company culture.
I recall one project that was originally built on a particular way .xml files were created. When the public increased their use of that system it caused enormous problems. It was too late to rework the entire project from scratch. But it does show how serious the fundamentals of underlying structure are, and the ability to scale up.
One project was led by someone like a ranting child in an adult body! There was no interest in having robust, reliable data. The solution that was put in place, by demand, used technology that was already recognised as insecure and faulty. It is no wonder that the technology was phased out at some point in the future, after the project went live.
We have many examples of how people behave and what results. The observation is that the SA deals with behaviours, diplomacy, and psychology.
The worst job I ever had was demeaning, brutal, controlling, like I was in a prison facility. I rebuked the manager when I left. I have seen a number of things around outsourcing over the years. Is it any wonder some organisations employ ex-military as part of the leadership? Such destructive environments of course still have people with their various IT roles in them, including the SA.
Despite all this, and there is a lot of “this”, a real SA is actually smart and creative. I hadn’t realised this. The workforce has a mix of creative and conscientious. You know, the designer or the accountant. We need both. When people do not understand this, they try to change people’s job role and force them into what they cannot do. It really annoyed some people that my job role was via a roadmap, not via external exams. The SA is approved in principle from their peers, including international, not attending a course on how to build projects. Their background of course has proved IT skill sets and project works with successes, as well as other content like principles of business analysis.
People can do all the certification courses they wish but still lack ability to “see” and make critical decisions. This means people may at times be likened to a truck that gets bogged down into the mud. SA’s find solutions no matter what, but do know when someone is stepping outside technology. This situation is more rare with its own issues.
In general, people do not hold the authority the SA has. They may have the right ideas but are afraid to speak. The SA gives this freedom and what may have seemed silly is found to be important as people talk to each other. With a plan in place, approved by the SA, even if only at a high level, people quickly rally together to make things work with great enthusiasm and energy. Even after a project completes it has its own life cycle where people continue to develop it by themselves.
The SA has access to all people in an organisation, from shop floor through to managers and the CEO. This means a wide variety of dispositions. A shop floor operator sees the SA for the first time and in the ensuing interaction will either like the person or reject them. Confidence and trust, being genuine are important. Sometimes people are trained in what they are supposed to say and do, but we see through this. Experience is part of the SA’s life. It takes work to fit in with other people’s territory including the jokes they make.
Once I did not get my hands “dirty”, so to speak, because I know I break hardware and do not comprehend maintenance of machinery well. The engineer was qualified to do the work. Because I did not jump in, he misunderstood and did not like me thereafter. It took time to show him why I could not and for him to see how I worked. Trust we earned, but it shows how something so simple can cause a huge problem up front.
There are many aspects to an IT solution. The SA will have people around who do not want to work together on a project, those who say their job cannot be replaced by someone else and so on. What do you do if a more senior staff member puts work into place that poses serious problems and they refuse to change it, preferring to hurt the people who have to work with that system? You will be yelled at. You will have people say you are trying to be on a pedestal. You will have people challenge your advice. This means we have to learn about a balance, where to pull back, or where and how to demand so that the project works, all with respect.
Despite a few ugly situations, we look for completeness of a project, not honing down into a subset of details. We are like an umbrella that pulls all the parts together with their interactions and what that means for people, those delivering a project and the stakeholders.
I had a project that encompassed the entire public communications work of a Bank. No one knew what to do. I recalled a data model I read about at University and presented that model. From there we built an entire solution and everyone took off into flight with it. The competitor has no such model. They focused on parts of the Bank and looked at pieces of software that they sold out of the box. That would never have worked. Interestingly, bad solutions are in my experience often given at much higher costs.
At a conference in USA, a major German company made a one million dollar deal with a new client for a software solution. I knew the software, that it could not do what they were claiming. The client appeared to be very happy. There was an alternative solution by people with the engineering expertise in the field who could deliver for fifty thousand dollars.
If anything, this tells us the SA continues to be active, to explore. In my first IT job, I was affectionately told I was like a dog, that I did not let go of the bone until I did what I had to do.
On one project in Australia, legacy systems were being upgraded. This was part of a huge project. One manager assumed that one of his staff could take the old data and push it through the software he was currently using on a PC. I had previously trained for years as an in-country specialist with IBM Australia, alongside my peers in Boulder, including the labs and developers and various managers. These were very intelligent people, one who even read Shakespeare at breakfast. We all got along very well, but I am aware that Australians can do things that are normal to themselves that are rude to the Americans. I have had various experiences with other countries as well, having insulted a manager from China for not getting on with it.
However, the PC software would fail. The SA needs to identify project gaps, and pitfalls. There was nothing I could do to change the managers mind about the software. The person who said it could work did not show why it would, and I had showed why it would not. That person was known to be “dopey”. He would fall asleep at the desk each day and was not suited to the work. His previous job was good though, and he had good colleagues. Something had changed over the years to end up this way.
I presented a professional solution with the commitment from USA to make the solution work, and we did actual proofs of concept showing it to work on rea data. It would take a few more weeks to complete the work as it involved reverse engineering.
A directive came from higher up to finish all work in a fortnight. It was not possible. As it wasn’t possible, the deadline never came into force. However, the manager wanted to ditch my work and use the PC software. It took a lot of forceful communications to hold onto the solution, which did complete and did work. What can I say? It shows a lot about people.
As one last example, I had to produce aircraft maintenance reports for Qantas at Avalon in Melbourne. These reports were printed and flown to Melbourne each night. Technology was changing. There was only one path to go down, which involved one piece of Unix hardware and software to transfer data between mainframe SNA and Ethernet printing. There was no other solution. It also involved myself writing programs. The solution worked. Qantas maintenance continued as we transitioned from the legacy systems. However, a senior mainframe engineer continued to tell me it would not work. I triple checked the documentations and testing but was even yelled at. Why? People do not offer alternatives, only tell you what you do will not work. I never had one failed project.
I think it comes back to the SA having ability to grasp the pieces and how they fit, seeing something in the future that will work, that is not yet in place. Not everyone can do this.
This ability includes the best interests for all parties.
As I developed early in my career, I wrote software on CAAD systems, learning how people think and work. I can tell if someone designs software that is awkward or difficult. People do not like to modify their bad programs. What we do becomes intuitive, based on experience. We need to maintain balance for the end users, as well as the clients who pay, and the people who give us a pay check.
For one project, there was a month’s deadline when $100,000 penalties would commence each month thereafter. No one knew how to tackle it. As I spoke to people, one manager said, this is how solutions should be. No one ever came around and simply talked with him.
I went into a small conference room with IT staff and said things like, what if we did this? I could do this bit. You could do that bit. We could try such and such….
The project leader called upper management on the spot and said yes, we have solution. And we did.
However, the solution needed constant review. Two people kept promising to deliver on time but never showed any proof that they were developing the work. This reached a critical point regardless of their stated confidence. The reality was they had done no work, had lied to me, and would not meet the deadline. Projects have dependencies. I hated it, but I made a checklist they could work through. I felt this was humiliating to all of us.
The project came online. No penalties. However, the solution was designed to stop the penalties. We had documented Phase 2 which would reduce the extent of manual labour involved on the basis Phase 2 had to proceed. It is risky when we assume people will continue projects in phases. The solution was criticised by shop floor staff, but we met the requirements. It took a lot of follow up work to assure people and to see others develop the solution until phase 2 was finished.
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.
I think our SA work grows in steps, appreciating previous project experiences. While my experience with the ANZ architects was a great experience, prior to this I had worked in Perth with really good people at Bankwest. People simply came to the foreground with their own expertise. While a complex project, in a sense it was easy. This is far different to one mobile phone company I worked with who bullied and verbally abused people to no ultimate value in the end. There are bad people in the industry, plain and simple.
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.
Along the way I have had mentoring and advice, even I recall once from American Express. They showed me some things of permanent value, but only because they knew I was real. And they put up with no nonsense whatever. Once a manager had failed to do his work so at the scheduled meeting they expressed themselves with no uncertainty and said they were ending the meeting, and left. I thought this was brilliant. I knew the humiliation we all felt and that the manager was not able to do this style of work. He too left the building. Real situations, real people. But keep in mind, in some other situation that manager would be perfect for what he does.
We will come across resistance at times to our work, without an apology after the fact. As mentioned, 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. We all agreed to the limits in our client meetings. 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. The company programmers in fact did not want to work on the algorithms. When we implemented them I had to use shell scripts to show how they worked, as I am limited with other languages. Code was developed but it did have an error as the programmer did not believe me when I detailed the error checking. As production had an issue he had to modify his programming to do what I had specified. This is how it goes I am afraid to say.
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 and was bought out. 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 point… 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. Sales teams typically wanted money, not a working solution. 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. For a solution to work, we would needed to have industry changes across all financial institutions. It would be possible. 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 from the public. No surprise, and no one won. This is how the SA thinks, in my view. That project was dead to begin with, so it died a slow death thereafter.
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.
As a side note, Technical Architecture is another professional competency even if there is overlap between SA and TA.
