IT Solutions Architecture roles vary among employers based upon need and structures available to them.
The role is primarily designed as a mix of oversight and senior skills to ensure successful project outcomes. This saves money. The role is proven to be true in that regard.
The role should come about by peer revue at local and international level (if possible). It is a common sense or logical progression in one’s career road map. Some people’s IT roles need exams and certifications that the SA does not necessarily require. There is a certain freedom the SA has across the board, providing access to all stakeholders from CEO to shop floor. The role is in a sense quite natural, giving confidence and enjoyment for others to proceed with their participation in a project.
A company may focus on in-depth detail and control if it is highly involved with that type of work, or it may be more high level with areas of expertise being facilitated by the architect and an agreed project blueprint. Often solutions arise because the SA helps people communicate anything they are thinking of, rather than limiting people or narrowing the knowledge about a project.
There is an aspect that is creative, imaginative, seeing the future of a project, how it can be brought together. This is kind of undefinable. Other people may fear for an outcome, or not be able to make decisions the SA can. It is therefore no surprise that the SA may do a lot of person-to-person communications, being willing to clarify or repeat things. One has an intuitive sense with people, spotting what they are thinking or need to hear. This is entirely different to some folks who simply repeat things thinking this will drill it into their heads. And, people do not work at their best if being told what to do.
Looking back over the years, my best projects were with Banks, who also have solid, formal architectural teams. The outsourcing businesses to me were highly depressing, like living in a prison. I had no choice but to rebuke a manager when I left one of those companies.
People get excited when they can see your vision and get on board to develop content via their skills. It is amazing to then see what other people do. Many of my projects solved situations where others could not see how to build a design.
A solution is usually called for with sufficient planning time, not always the best though, but there can also be a crisis. While we have certain practices for our profession, these can be put to one side with what comes out of the blue. Flexibility is a good thing to learn. Most people find this out of reach, where things must be done one way, where people must agree with them as they feel they are right. And herein lies psychological understanding.
We do not consider one component of a project, but all of them, then how they relate to each other with their dependencies. This is an umbrella approach, addressing end-to-end solutions. Competitors frequently produced bits and pieces related to a sales pitch, not offering what would work for all people in the fuller context. It is a bit like the approach of sales reps telling a customer to read a product brochure, rather than sitting down with them to learn of their pain, and offering a discussion on what would be benefits, and then, then offering an IT design.
Like human nature everywhere, there are misuses of the SA title. Some fail to see what it is, and attempt to rebrand it into something else, or simply offer the job role to people who are not given the full freedoms, authority and responsibilities of the role.
The SA spots things, not to be telling others they are wrong or how bad they did, but simply seeing, and where able, to help by normal discussions day-to-day. Like human nature again, some do not want to be a part of this and therefore take offense, so they would rather provide results that hurt the people who have to use their work. Most end-users will not understand IT, so they believe they have to use what is given to them. This applies to technology used in any time period – the 1980’s, 1990’s or today.
My understanding of technology was helped by developing Computer Aided Design systems in the 1980’s, seeing how people interact with software. This is a learnt skill that only a smaller number of people develop in a truer sense. My skills were also supported by detailed work in the Unix system, with business applications, critical problem solving, and many areas of support IT in hardware and software, including soldering wires, and configuring routers and modems!
We have many examples of project testimonies, quite surprising, but how does this help? Project ownership is a group concern. If we can spot problems up front, we have invaluable results. For example, prior to engaging an SA on a project, a database system was put in place using .XML files. The amount of XML structure for little internal real content was so great, it took many hours to process time critical huge files, every day. As the public increased its use of the service, the hardware and software floundered under load. Post-SA involvement could not of course change the structures already built, or be of any value to criticise, but input helped others in dealing with the severity of the problem.
On one project, there was to be a $100,000 penalty each month, and no one could find a solution. The SA approach was to look at a high level design with a viable roadmap. In a meeting, we simply talked about what-ifs, rather than telling people what to do. The solution unfolded very rapidly as everyone jumped on board. It took on a life of its own, even though certain core components were directly under the SA’s eye. People commented on how they had thought some of those things we discussed, but had been afraid to do so. There was much happiness, but the solution was still designed only to meet the need to avert the penalty. It had to have a phase two in order to reduce certain manual processes. The structure allowed people to continue developing processes without the SA.
I have had a number of projects where I have been yelled at, bullied, threatened to have the project removed, or resolutely told the project will not work. The SA has to deal with such things. All of my projects worked, without fail, just as I can proudly boast that all of my earlier work never had an unsolved mission critical problem, none of my disaster recovery jobs ever failed, and I never brought a system down in a business or a data center. Throughout my career I was transparent and never bowed down to hiding or blaming others.
My “philosophy” was to contribute, to lift the bar, to enjoy receiving and giving mentoring, and to follow principles such as best practices and learning. It was always good to think where one could contribute beyond simply providing what was asked. Always, I would pursue a line or research or discovery without having to know why or to what end, and later it would prove valuable in order to build further. I was very fortunate to have good managers and staff helping me learn over the years – despite the bad ones too, who are always there. I also had access to a number of people and resources higher up in the industry, such as developers, labs, in-house documentation. It was quite hard not having this when moving from those larger companies to smaller ones without the same resources or interest in education.
On one project, the client insulted an entire IT team. As SA I knew the client was acting with little knowledge. The client was not interested in how technology works, or a robust and reliable system when discussed. After the project went live, it had to remove some of the content that had been demanded as it was not technically fit – no surprise. We do face rude and childish people.
We also come across sales force staff who try to sell software that does not do what they say it will. That is a bit f a head twister as the rep may not want to understand.
I have many examples. An observation is that the SA deals with behaviours, diplomacy, and psychology. It is a balance – where to pull back, where to talk in detail, where to listen, and sometimes where to insist. Not everyone wishes to work as a team.
I’d like to give more examples later on my website, but this is enough for now. The lesson is that we may develop confidence in what we do, because our work shows validation and success. We do not just build a home without a roof, or forget to put concrete in the foundations. We learn about best business practices, project principles, and IT standards. This takes time. We have a vision of a project structure and outcome which then helps others who do not initially see this, or who panic and need reassurance during development.
As designers, we need to develop our awareness and practical use of industry best standards. In the IT world, this content is not found in a text book. It involves identifying and mitigating or removing unacceptable risk, lessons others have shared, how we work with development and live servers, specialist documents and news, networking with others, conferences, training and more.
For example, testing a proposed software change with formal check lists, backing up the live system, moving it into production in an agreed time slot, having ability to put back original code if a problem, and post monitoring. There are cardinal rules one does not break. We have however seen absolute disregard for this industry practice with large scale consequences. There is also unexpected human error of a different kind. A highly competent colleague once flicked a mainframe switch by mistake, thinking it was necessary for rebooting the machine. It was the power! Various services across Australia suddenly went down.
All this work is done while considering the interests of all parties, not just one. Those who are onboard make projects easy, regardless of complexity. Those who are dictatorial, who reject cooperation and teaming, or even those who are way out of scope for the role they are in, can make a project very difficult to design and execute.
Over the years, I worked on small to medium, and large to top tier projects. From this background I am able to pull back these enterprise demands to some simpler approaches that help us in less demanding projects for our websites or applications that run under the Amazon (or similar) architectures. To keep in mind though, is that not all projects will work, and I have examples of this too. We should consider our own protection and liability for what someone else asks of us or things technology does not do.
We may also face systemic problems rather than technical solutions. It is very rare that we decline a project, indeed, but we do need to be careful when acting as an individual or sole trader, and to develop ability not to let things sit unanswered that niggle at us, because what you think may not be what the client thinks and vice versa, even though we thought so. We cannot let smaller points of a project slip by, as they always resurface.
As a side note, Technical Architecture is another professional competency even if there is overlap between TA and SA.
I would like to encourage our thinking towards solutions rather than building blocks. Blocks fit in once we have a solution in mind, which of course can be dynamic. If the footings are right, we will be able to modify what we do as we need. This is an approach a lot of the IT workforce struggles with. We have more freedom, which is why perhaps I have felt deep satisfaction.
These principles and experiences work just as well for small to large multi-million dollar projects as they do for those of a couple of thousand dollars such as our websites. I would like to contribute to our understanding of good website project practices where we seek to compose a story for each client, ensuring we have the content needed.
All of this means nothing for those who do not hold the values I have indicated here. We have limited time to give a small project, but we will benefit from these discussions, and I trust you will see a difference between a good website that even goes one step further to suddenly take it to the next level, compared to mundane or just bad sites. As I cover end-to-end solutions, we will look at all the key aspects of the Amazon AWS EC2 platform via this website, and associated website services such as SEO optimisation, security, performance and maintenance.
