Every now and then I seem to be going over a bit of an identity crisis, so I have to remind myself what is it I do best and how is it different from what some may think I am supposed to do.
So let’s see if this makes sense… but let’s start from waaay back.
By the time information technology became a separate discipline, which is really not that long ago from the historical perspective, a lot of other disciplines, jobs, professions, and activities had long been established. Not surprisingly, quite a few role and activity names in the IT have been borrowed from those other areas, and, for example, when it comes to the “architecture” and “engineer” roles, they seem to have originated from construction, or, at least, there are lots of similarities there.
So, let’s look at the construction first to get a slightly different perspective / to draw some analogies. Those who are, actually, in construction, please forgive my ignorance. I was doing some reading, and I’ve seen how it’s actually not that simple to explain the difference between an architect and an engineer, for example, but, guess what, it’s the same problem in the IT.
Either way, I was looking for a simple and concise explanation of what architecture is in construction, and I got this:
“Architects collaborate with clients, engineers, and other stakeholders to develop plans that meet the client’s needs and comply with building codes and regulations. Architectural engineers, on the other hand, bring specialized technical knowledge in engineering principles and systems to ensure the structural integrity, functionality, and safety of buildings“
(Quoted from Architect Vs. Architectural Engineer: Differences, Similarities, Duties, Salaries, And Education (architecturelab.net) )
With that in mind, let’s try drawing a diagram to see how various roles presumably work together in the construction and in the IT. There might never be a clean cut role to be fair, but what if there were… You’ll see IT roles in “blue”, and there are matching construction roles in “grey” below:
This seems pretty simple and straightforward, but what actually complicates it, at least in my mind so far, is not that the roles are not clear, but just that someone on the actual project would often be wearing different hats.
For example, a Solution Architect might play a Software Architect or even an Enterprise Architect role at the same time. And that’s not even such a far-fetched scenario, by the way, since I often see a mix of those activities in the job postings.
Or a Business Analyst would try (or would even be required) to take on a Solution Architect role as well, which is where things will start getting messy since someone would be constantly crossing the boundaries of those different activities/responsibilities, while they can all be time consuming and can require specialized skills. An analogy would be for a mayor to take on design and architecture. Most likely, they just won’t be able to come up with anything remotely feasible unless they do have required background/certifications/experience.
Either way, one interesting outcome from the diagram above is that solution architects produce plans and designs, not necessarily the final products. Which is, again, why their job is often confused, to an extent, with that of business analysts, but those are completely different flavors of plans and designs.
When there is a business requirements (or when the city says “we need a new bridge”), there can be specific business expectations (the system has to do this and that… or the bridge has to have 2 lanes and a bicycle lane in each direction), but the actual plan/design of the system/bridge is for the architect to do (in accordance with the expectations), and, then, someone has to build the system/bridge based on that plan/design while using proper materials and techniques.
I’ve been finding myself in a somewhat peculiar situation on the projects, though. Historically, I stopped feeling as being a developer 10+ years ago, so I started to say that I’m a D365/Power Platform consultant, and I probably am, but I’m also a Power Platform solution architect, and that’s a little vague. In reality, I think I tend to fill in solution architect role on the Power Platform projects just about all the time even if, ultimately, I also have to do some software architecture and some development on the same projects.
So let’s make it clear: I design Power Platform solutions.
Which does include digging around for the proper technology, figuring out if the client can compromise on their requirements, what needs to be done to make the solution work with the existing enterprise architecture, what needs to be prototyped to confirm certain things and to review those prototypes with the business team. Which means I am a bit of a “jack of all trades”. No, I don’t really know everything upfront. I don’t know everything about the licensing, I don’t know everything about software development, I don’t know everything about Canvas Apps, Model Driven apps, Power BI, Power Automate, React, etc. I know very little about Copilot yet. But I do know quite a bit about most of that, and that allows me to see what’s doable, what’s not, and how it can be done. And then I can prototype and confirm. And, of course, then I can develop etc, though… sometimes I don’t necessarily want to be that hands on other than in order to better understand how things work for the next project.
However, I’m also getting a bit tired of having to mix different roles. For example, I don’t necessarily think I’m a good software architect (moreover, there have been at least a few precedents in my career where a seasoned software architect would quickly recognize an imposter in me 😁) I am also not that good in the Enterprise Architecture, since I tend to focus on the specific tools, which just happens to be Power Platform at the moment.
So there we go, I do solution architecture on the Power Platform projects, and that includes:
- Understanding the business process and related requirements
- Prototyping, presenting those prototypes to the client, reviewing implementation options and alternatives
- Considering related organizational policies, reviewing security requirements, possibly becoming familiar with the regulations
- Preparing required documentation, high-level designs, identifying the risks, possibly identifying the milestones, features, epics etc
- And, often, working on the actual development afterwards and / or leading the team from the “solution design” perspective
And, with that, one more round of self-identification exercise has come to an end.
However, there is one last note. If you are looking to engage a Power Platform solution architect and a former MVP to do some of the above on your project, feel free to reach out on Linkedin. I’m not for hire in the full-time capacity, but I’d definitely be looking to extend the variety of my projects, since how else can we all stay up to date if not by getting involved on all sorts of projects.