Blog of Shaun McCran - Architecting robust, elegant technical and business solutions

Adventures in Lego: the UCS Millennium Falcon (75192) – post 4 - bags 9-12

Mon, 29 Jun 2020 23:16:00 -0000

This is my ongoing blog series on building the Lego Ultimate Collectors Series Millennium Falcon, here's a link to the Lego site: https://www.lego.com/en-gb/product/millennium-falcon-75192

This is a 7500 piece kit, so its a big build! The biggest Lego set created in fact!

A quick recap of where we are 8 bags in. We've got a complete Technics framework, a couple of of room areas, the front V shapes and the back end. This article will deal with bags 9 through 12.

[More]

Adventures in Lego: the UCS Millennium Falcon (75192) – post 3 - bags 6-8

Sun, 14 Jun 2020 11:45:40 -0000

This is my ongoing blog series on building the Lego Ultimate Collectors Series Millennium Falcon, here's a link to the Lego site: https://www.lego.com/en-gb/product/millennium-falcon-75192

This is a 7500 piece kit, so its a big build! The biggest Lego set created in fact!

A quick recap of where we are, 5 bags in. We've got a good sized Technics framework, and a lot of detail in the four room areas and the back end. This article will deal with bags 6,7 and 8.

[More]

Adventures in Lego: the UCS Millennium Falcon (75192) – post 2 - bags 3-5

Fri, 12 Jun 2020 16:52:00 -0000

Following on from the last post, where I unboxed and started the build for the UCS Millennium Falcon, I thought I'd outline the next few stages, so you can see how it builds, and what issues you might find in the building process.

The first article was opening the box, looking through the manual and steps 1 and 2. This article will cover 3,4 and 5. Also some minor back tracking due to my inability to count spaces properly!

[More]

Adventures in Lego: the UCS Millennium Falcon - 75192 - unboxing

Sun, 07 Jun 2020 20:45:00 -0000

I had the pleasure of picking up an Ultimate Collectors Series Millennium Falcon recently, so I thought I'd write up my findings on opening the set, a stage by stage view on building the set, and generally how the thing translated into Lego. [More]

A career change, a blog hiatus, but I’m back to it now

Sun, 26 Apr 2020 14:38:00 -0000

It has been a while since I wrote any blog articles with any consistency. Like so many things in life, it was not a conscious decision to stop blogging or sharing knowledge. More that my day to day activities changed, and, as many of us do, I found new opportunities to drive myself forward that did not necessarily align to my historical skillset. The hands-on work started to take a back seat in my day-to-day timetable. Coding, Information Architecture and User Experience design. All these things started to get left behind, while I moved through Architecture roles, eventually leading teams of people in the roles I'd previously held. The things I really enjoyed during previous roles became hobbies that I practiced in the evening, such as mobile development and JavaScript apps. As you distance yourself from skills you used to use on a daily basis, skills you used to teach others through mentoring programs, the opportunity to blog about them became smaller, and my focus turned to driving my new skills to a point of maturity. The process of becoming the trainee again, in new skills, such as understanding team members personalities, defining Enterprise Strategy, effective team management and successfully engaging with C grade stakeholders was a great personal challenge. The opportunity to step outside your comfort zone and learn new things is something I've always relished, but it does lead you to a place where you have a sharp learning curve, and you are no longer a master in your field. That tends to impact on your ability to blog on a subject with authority, or as a subject matter expert. So! Its been a long journey. I've moved across several new disciplines, and now I'm getting that nagging feeling in the back of my head again. I've got views to share, best practices to push into the public space to talk about, and collaborate over. Its time to start blogging regularly again.

How Swindon Inchcape Audi destroyed my faith in the brand, and that specific dealership

Sun, 16 Feb 2020 15:50:00 -0000

How my Swindon Inchcape Audi meeting destroyed my faith in the brand, or at least that specific dealership. - Friday 17th January 2020 To set the scene, I'm 3 years into a 4-year PCP. this is the first Personal Contract Purchase vehicle I've owned, so its all a new experience, and as it's a premium brand, I'm was expecting an actual 'Experience' rather than a basic journey through facts and figures. With that in mind I booked an afternoon appointment to go through figures and options for a 3-year-old PCP, Audi A4, and look at booking in a set of test drives for replacement vehicles. Our appointment was with a salesperson that we didn't have a previous relationship with, as ours, Richard, left a few months after selling us the car. Let's call the new chap Lee, that was his name, so let's use it. We sat down and had a brief intro, I asked him if he was having a good Friday, as typically people find Fridays to be a happy day of the week, to which he replied, 'it's another day, at least its not the weekend'. So not a glowing start, and a slightly weird beginning to the conversation. [More]

Examining Leadership: Retaining your talent

Wed, 09 Nov 2016 03:32:00 -0000

I've noticed more and more than leaders spend a lot of time talking about talent, but appear to make the same mistakes over and over again in growing and managing it? Over the last year I've moved through the steps of an internal, formal leadership training process, all with the end goal of examining what the wider perception of what leadership is, what it means, and leaders are displaying those leadership qualities that set them apart. Its also a good way to demonstrate to parties that need that sort of thing confirmed, that you know what you're doing.

With all the emphasis on building and displaying leadership development, I've noticed that there seems to be a huge struggle with being able to retain the top talent. Having an existing leadership team in place that can identify the potential for others to grow is great, but they have to know what to do with those people once they get there. If there's an internal career superhighway for ambitious employees to pick up new skills and demonstrate themselves, there has to be an agreed, recognized end of the road, otherwise that career progression journey will take them straight out of the door into the market.

I've learnt that when you want to examining the talent growing process at any organization look at the culture, not the rhetoric – look at the results, not the commentary about potential. A disjoin in perception vs reality was accurately summarized from a recent industry survey, when employees were interviewed, here's what they said*:

1. More than 40% don't respect the person they report to.
2. More than 50% say they have different values than their employer.
3. More than 60% don't feel their career goals are aligned with the plans their employers have for them.
4. More than 70% don't feel appreciated or valued by their employer.

So, for all those leaders who have 'everything under control', you better start re-evaluating. The old saying that goes; "Employees don't quit working for companies, they quit working for their managers." Regardless of tenure, position, title, etc., employees who voluntarily leave, often do so out of some type of perceived disconnect with leadership.

In my experience I've found that employees who are challenged, engaged, valued, and rewarded (emotionally, intellectually & financially) rarely leave, and more importantly, they perform at very high levels. However if you miss one, or some of these critical areas, it's only a matter of time until they head for the open market.

Below are some key reasons that I've seen talent leave a company. As a leader, keep an eye out for these things and make sure you aren't doing them!

1. You Failed To Unleash Their Passions: Smart leaders align employee passions with corporate pursuits. Human nature makes it very difficult to walk away from areas of passion. If you fail understand this and you'll unknowingly be encouraging employees to seek their passions elsewhere.
2. You Failed To Challenge Their Intellect: Smart people don't like to live in a dimly lit world of boredom. If you don't challenge people's minds, they'll leave you for someone / somewhere that will.
3. You Failed To Engage Their Creativity: Great talent is wired to improve, enhance, and add value. They are built to change and innovate. They need to contribute by putting their fingerprints on design. Smart leaders don't place people in boxes – they free them from boxes. What's the use in having a racehorse if you don't let them run?
4. You Failed To Develop Their Skills: Leadership isn't a destination – it's a continuum. No matter how smart or talented a person is, there's always room for growth, development, and continued maturation. If you place restrictions on a person's ability to grow, they'll leave you for someone who won't.
5. You Failed To Give Them A Voice: Talented people have good thoughts, ideas, insights, and observations. If you don't listen to them, I can guarantee you someone else will.
6. You Failed To Care: Sure, people come to work for a paycheck, but that's not the only reason. In fact many studies show it's not even the most important reason. If you fail to care about people at a human level, at an emotional level, they'll eventually leave you regardless of how much you pay them.
7. You Failed to Lead: Businesses don't fail, products don't fail, projects don't fail, and teams don't fail – leaders fail. The best testament to the value of leadership is what happens in its absence – very little. If you fail to lead, your talent will seek leadership elsewhere.
8. You Failed To Recognize Their Contributions: The best leaders don't take credit – they give it. Failing to recognize the contributions of others is not only arrogant and disingenuous, but it's as also just as good as asking them to leave.
9. You Failed To Increase Their Responsibility: You cannot confine talent – try to do so and you'll either devolve into mediocrity, or force your talent seek more fertile ground. People will gladly accept a huge workload as long as an increase in responsibility comes along with the performance and execution of said workload.
10. You Failed To Keep Your Commitments: Promises made are worthless, but promises kept are invaluable. If you break trust with those you lead you will pay a very steep price. Leaders not accountable to their people will eventually be held accountable by their people.

To summarise, as a leader, you need to spend less time trying to retain people, and more time trying to understand them, care for them, invest in them, and lead them well, then retention will take care of itself.

*Statistics rounded out to show trending rather than specific figures.

Why should you invest in Architectural qualifications?

Tue, 18 Oct 2016 15:05:00 -0000

As part of an ongoing series of articles covering the skills and process that people go through in order to move into architecture I thought I'd have an exploration through the landscape of professional qualifications. The key discussion topic was driven from a recent conversation on whether architectural qualification are valid, whether they enhance an architects skills or validate the architect as being more 'architecturally capable'.

I've split the article into what architectural qualifications mean to several different parties, such as individual architects, companies that use architects and the architectural industry as a whole. This is mainly because each of these parties have very different requirements and goals around professional qualifications, reasons to obtain them, and what value they provide.

The Individual view

For the individual architect obtaining a professional, industry recognised qualification can bring several benefits. First, architecture can sometimes be a little intangible. We don't physically produce anything, and often what we produce is proprietary for the industry we are in, making it very hard to measure the quality or validity of output. Possessing a qualification such as TOGAF proves that you know the correct terminology, can recognise architectural artefacts and impacts and are likely to provide architectural documents to a reasonable standard. Its treated somewhat like an architectural 'kite mark', ensuring that there is an inherent quality to the content.

For the working architect its also good to know that your colleagues and peers can understand the content that you produce. If you create a TOGAF or Zachman aligned document you want to know that your colleagues can consume it, and that as a practice it will fit into your overall approach.

Lastly, it makes you a more attractive resource, if you are seeking employment. It's a very good selling point for recruiters and employers as, explained above, its an industry standard, so brings with it a certain quality level when filtering applicants for a role.

Corporate view

Companies can often see qualifications like the ones described here as being overly academic and not really driving their overall goals, in terms of focussing on delivery or project specific issues. Qualifications can be an expensive and timely activity to put your teams through, so are often sidelined entirely, or put at such a low priority that they never materialise. Delivery objectives take over, and all the talk of being a 'people organisation' goes out the window.

Key things a company has to recognise though is that endorsing a professional framework can provide many benefits to them:

1. It shows potential recruits that they are serious about their architecture and that they are prepared to invest in their people
2. It's a handy metric in the review process. Send everyone on a course, and their pass mark is a very good metric in what can be a very ambiguous process (employee reviews)
3. Where a practice aspires to ensure a consistent level of service to other departments from its architects, knowing that they are all qualified to the same level, and know the same content. This somewhat equalises the organic way a team forms.
4. Lastly it's also a good measure of capability. It may sound harsh, but being an architect is a hard role to perform successfully and consistently. If you are unsure of the calibre of the people in your team, an effective way of measuring it would be to send them on a course and measure the results. Similarly if you are trying to build a trainee or junior architect programme they can serve as a good graduate gateway. If a graduate architect wants to consider themselves a fully functioning member of the team, then passing TOGAF or the BCS qualification should be a required qualification.

Industry view

In terms of industry recognition, possessing industry standard qualifications gives you a place in a larger community. There are often social activities and online groups that you can join and participate in. When you look at an architects profile online, there are few keywords that indicate evidence of qualifications and experience. TOGAF, Zachman, BCS and ISEB are the key words I typically look for to determine if a candidate is not only affiliated with, but claims accreditation with one of these bodies. This marks them as a professional architect.

Types of Qualification

There are two recognised industry qualifications for architects, one is based on the TOGAF framework the other being a British Computer Society accredited qualification in Enterprise and Solution Architecture. Obviously there are many books discussing architecture and architecture processes, and even other frameworks such as Zachman, but none of them contain courseware, exams and accreditation processes.

TOGAF

TOGAF is very much a framework. By this I mean it is not a guide as to how to be an architect, it will not tell you how to do the day job, but rather describes an approach. It's a standard methodology and process to enable you to take up an out of the box toolkit. It should, however not be applied in this format. Success with TOGAF is very much a case of assessing the framework, trying the elements out in your organisation and seeing what works for you and does not. If you try and wholesale adopt TOGAF as your architecture practice's methodology you will rather quickly find yourself hitting issues with delivering anything.

BCS, Enterprise and Solution Architecture

The BCS, previously ISEB, course is a tough one. Its an intensive course, covering a lot of content. My advice with this one is that it is not a purist architecture course. You'll need to be aware of ITIL, PRINCE2, Six Sigma and a slew of coding and development technologies. It doesn't require you to have in-depth knowledge on those subjects, but rather to understand what they are, how they work, and how they interplay with architecture. My recommendation is that you have to be a practicing architect, with a few years experience in a tough environment to pass this one.

How good is your recruitment and joining process?

Fri, 14 Oct 2016 07:18:00 -0000

I'm involved with recruiting new colleagues, typically architects of different flavours, into the architecture practice that I'm part of, this process, like most other company's recruitment and joining processes is a multi stage, multi format process involving many different people and many different touch points with candidates. It has the potential to become complicated and unwieldy, extending itself out over undesired periods of time.

Working as an architect you tend to spend a fair bit of time looking at business processes, mostly outward facing processes, or processes that drive the overall business objectives, but every now and then we turn our eye to our own internal processes. This article examines how having a poor recruitment and joining process can have an adverse affect on both the new team member, and the existing team that are involved in the process.

The recruitment and joining experience, more important that you think

Having a new person joining your practice is a key impression shaping experience for them, it will form their initial view of people involved, and the overall team, and the maturity of the team. Think of this as the first handshake of a meeting, you remember that don't you? You know how when you first meet someone, you shake their hand, and that action is forever associated with them. 'John' forever has a handshake like a wet fish, limp and uninterested, whereas 'Susan' has a firm, but not too firm, authorative, confirming handshake. Everyone's is different, but they all leave a lasting impression about that person. Your recruitment and joining process is no different, just significantly more complex.

The danger here is that the people performing this process, whether that is existing team management or Human resources may see the activity as just that, a series of activities, the physical actions of the process. Often this is not the existing managers core responsibility, they have a 'normal' job to do, and this sort of thing isn't typically as important as that job. Its highly unlikely that any of them have objectives around how many candidates they recruit, or even more significantly retain, so its treated with less priority than it should otherwise have.

Typical activities might be:

1. Review CV's
2. Conduct telephone interview
3. Conduct face to face interviews
4. Make recommendations to cost centre management about candidate suitability
5. Communicate offer
6. Order a phone and laptop
7. Request the right access privileges (AD accounts etc.)
8. Order a security pass
9. Send out a 'first day instructions' email

Now, there are obviously physical tasks to perform here, but most of these can, and often do have an outward facing impact on the candidate. That's the factor that is often overlooked. When times are busy, and everyone has project work, or partner relationships to manage, investing time and energy into ensuring a smooth recruitment and joining process can often be the first thing to suffer.

It's a maturity barometer

Aside from creating that initial impression with new employees it is also a good mark of how mature a team is, and potentially an organisation. I like to think of it this way, if a company has mature, well thought out recruitment and joining processes, there is a strong chance that the rest of their internal and external processes are also well thought out. The opposite is also true in my experience. If they cannot recognise the importance of these processes, including the impact they have on morale and the future engagement of employees, then there is a strong chance you may find they do not have the rest of their house in order.

Recruiters, treat your role advertisements as if they were first dates

Tue, 11 Oct 2016 15:16:00 -0000

My most recent interactions with recruiters, both from agencies and in-company, have left me slightly bemused by how they perceive the balance of the employee - recruiter relationship. I've had several experiences where this newly burgeoning relationship has felt very one sided from the very first contact and has been difficult to progress very far due to significant reluctance on the recruiters part to share any information at all.

Recognizing that their objective is to locate a candidate of sufficient quality to get into the face to face interview stage I can normally give them a little leeway in their single mindedness, but there seems to be a growing trend of only providing information pertinent to the employer, not the candidate.

So with the issue above in mind I've put this article together to explain the key elements that I think recruiters MUST include in their role advertisements to ensure that both candidates and recruiters have access to the information they need to make a reasoned, informed decision on the role. I've equated this to a dating analogy, as whilst thinking this through I found that I could draw some simple parallels between the two scenarios.

Think of the 'first date' scenario. Two different individuals meeting for the first time, each giving away small items of detail about themselves, revealing information that might make them appear more attractive to the other, but not quite revealing the entire picture. Each person is judging exactly what the best pieces of information are to reveal, what information they think will portray them in the best light, what will create additional interest, causing the other person to want to dig deeper, to create a more meaningful engagement. Each person has specific expectations from the other, there are typical subject that are normally covered and it all normally happens within certain civilized constraints, i.e. everyone wants certain snippets of common information, but is also aware of staying away from controversial topics. This is all jockeying for position to assess compatibility.

Now lets apply that thinking to the initial conversation between a recruiter and a candidate. Recruiters are trying to ensure compatibility between their role and the candidate, yet often they only come to the table armed with the specifics of the activities of the role and little else. Its fine for them to have demands of candidates, but in my view they also need to cover the following things to ensure that they are giving confidence and assurance to candidates that they actually care about compatibility with them.

1. Business model and moral compass: What the company actually does, how it makes its money, i.e. its business model and how it sees its self in society, i.e. its moral compass. How do you judge whether it is agreeable to your own, if this is omitted from the description?
2. Company sector and product set: What types of company are they? Financial? telecoms? Marketing? What do they sell or manufacture? It's not uncommon now to find advertisements that don't actually list what type of company they are, or whether the role is specific to a certain product set.
3. Salary and benefits: Always a controversial one this, but so many advertised roles do not feature a salary figure, or even a salary range to give an indication of where it sits within the market. This is a key factor for candidates, but also a key bargaining chip for recruiters so is often the last thing they give away. The other important factor with the salary figure is that it is an extremely good marker for the role's expectations. A high figure, or something that stands out from the market is likely to include other factors that in the role that warrant that figure. No salary is too good to be true, there will always be something in the role definition that has impacted that figure. An accurate figure also shows that the company advertising actually understands the role well themselves, and its position within the market. You have to balance this figure with the next point, the location.
4. The role location, and travelling demands: Pair this with the point above about salary and you have two key counterpoints to each other. Location obviously dictates where you base location is, but also consider travelling requirements as these can, and should have an impact on the salary. Regional locations, cities, secure sites and remote offices all play a factor in influencing both salary expectations and the level of comfort around commuting and the lifestyle impact taking the role may have on you.

To summarise, I think we need to redress the balance between recruiters and their market. If the four points above aren't covered in an advertised role then for me, it shows a lack of attention to candidates requirements, and a misunderstanding of how to create a quality engagement situation, that communicates what each party is actually looking for. If this was a first date, you wouldn't be getting a second.

As an example of this, take a look at the following role advertisements:

Architect roles in Nationwide

Conceptual, Logical & Physical views of solutions

Tue, 13 Sep 2016 03:01:00 -0000

There is a common sets of views that architects have to be able articulate, typically for different audiences, each of which describes the same solution but at a different level of detail. Anyone prescribing to be an architect should be able to clearly articulate these three common views, why they are necessary and how they link together, as there is a strong traceable model between them.

A while back I took a role in mentoring some less experienced architects with an aim to solidifying their architectural thinking and moving them out of a Business analysis and design way of thinking. As part of this in-house upskilling programme I started writing an example of the 'Conceptual-Logical-Physical' views and their relationship. Whilst researching it online I found the example below, from the Zachman site. This is a great example, and clearly shows why the three views exist, and how they convey the right level of information to the correct audience, allowing each role to perform in its own space with, aiming at the same solution, but not restricted by any of the other roles around them.

Conceptual, Logical, Physical architecture example

The "Owner": CONCEPTUALLY ..... "I would like a pot of flowers in the center of my patio about 10 feet off the ground. They would be purely for ascetic reasons, but I want the pot to be BIG and the flowers to be real."

The "Designer": "Let me see now ... the physics of this situation would suggest that there are two LOGICAL alternatives ... either 1) you would have to have a pedestal about 10 feet high, the weight it would have to sustain is max of 100 pounds so if it was 10 square inches in area (cross-section) the material would have to hold 10 lbs per sq. inch. You're second alternative 2) would be to hang it from something above the pot ... do you have a roof over the patio?? If not, that would mean we would have to construct a tripod to suspend the pot from the apex. Do you care if you see the tripod? I recommend you go with the pedestal."

The "Builder:" "The Architect is suggesting a pedestal that would be 10 feet high and sustain 10 pounds per square inch. That Architect wouldn't recognize a lathe if he fell on one ... but here's what we could do ... we could PHYSICALLY build the thing in three pieces and then glue it together with superglue ... just in case, we could make flanges on the pieces so we could bolt the pieces together to make sure they don't come apart. Your other alternative is to have it made in Japan and ship it in one piece and then we could install it by drilling a hole in the patio, sinking the base down 2 feet and filling in the hole with cement.

For full disclosure, I have republished this from the Zachman site, the original is here

Is there a fast track to becoming an Architect?

Mon, 12 Sep 2016 05:22:22 -0000

The last few articles in this series have documented what I consider the standard approach to becoming an architect to be, the TOGAF role structure and the key concerns around performing the role of an architect day to day. I've built the foundation of understanding the role, specifically to ensure a level of understanding of the attributes and activities of an architect. This is key, as in this article I'm specifically looking at the idea of whether or not it is possible to fast track the journey to become an architect. Posing the question, could you take an individual with the capability to perform the role and move them in quick succession through a series of tasks to establish possession of the skills required to operate as an autonomous architect in their own right. Let me start by saying that there are several assumptions associated with this scenario. The individual, the 'candidate architect' would have to be aware that they are on a journey to display their skills as an architect. The capacity or capability to perform the role would have already been pre-judged as being present, and the candidate would have a knowledgeable support network around them.

What should they be tested against?

As stated above, I've already put together my view on the activities an architect performs. There is a key factor here in differentiating between architects and subject matter experts (SME's). This is import in that these two categories of role are very different, but can often become confused with each other. To understand exactly 'what' we should test candidates against we need to understand the difference between these two type of role.

Subject matter experts

Subject matter experts are people with deep knowledge in a business area or capability. They have deep understanding of their area of functionality, but its a very narrow view. Typically their skillset is specific to a field of business services or technology, such as payments, networks or services. They do not have a breadth of insight across multiple fields or processes. This makes them ideal team members if you want detailed information, at a very granular level, but if you want someone who can be reapplied over many content areas, SME's will struggle as they will be outside of their comfort zone.

Architects

In comparison to the SME description above, Architects have a much wider breadth of knowledge across many fields of technology and business capabilities. They may have more detailed knowledge in one or two fields, specifically where they came from, but as a rule they have limited visibility over other process and technologies. This means that as a member of a team, they are deployable across the whole spectrum of a solution as their skills are not specifically tied to one area of knowledge.

Flexibility and not detailed knowledge

From the descriptions above we can determine that the skills an Architect should have are not based in a specific technology or business process. They should sit above this, as they should understand how to examine and interpret technology solutions and business processes, but they should not have detailed knowledge of them, as that's why you retain your SME's. When you consider this, it effectively dictates what you would ask a candidate architect to prove. You would NOT ask them to understand each of your business areas, or processes, but instead ask them to show the skills to discover those areas, integrate with the SME's and extract the right information that is pertinent to the solution.

What's missing from this process?

The above describes the technology and business process discovery but it intrinsically hints at needing stakeholder skills and interpersonal skills to be able to operate successfully. They are a little harder to measure as they are less tangibly proven. The second big factor missing here is the experience and ability to handle the pressures of going through this process. Knowing a task is one thing, but presenting that task back, thinking around it, defending your position when appropriate, or moving on it when its not, are all skills gained from actually going through the architectural process. Experience of previous roles gives people a depth of character that gives them confidence within a business operating model. At its simplest description, discovering and documenting options is a key skill that can be learned. Presenting that options paper back to senior stakeholders with confidence, explaining the process, facing down challenges and holding your nerve is an entirely different skill that is not learned, but more like 'forged' through going through the process repeatedly. So in summary, I'd say that yes, there is a fast track to 'learning the skills required to operate as an architect'. But I'm separating out that just having the skills does not mean that the candidate can operate as an architect, they need that forging experience to have the confidence and prescience in a room to carry through their architecture directives.

What do you need to know to become an Architect?

Fri, 05 Aug 2016 06:48:00 -0000

Approaching this topic as an Architect, I've taken the view of splitting this into two parts, the first is an overview of the MetaModel that describes a professional role, the second is more extensive and applies that MetaModel onto the Architect role.

MetaModel for a professional role

Any professional role comes with a common set of terminology, activity description (processes) and method that allows for a common language within its industry. Architecture is no different from this, for example, if you are a practicing Architect within company '1' and you move to company '2' there should be a consistent set of architectural language across both companies, within some variances, based on company practices.

Similarly because the activities, the 'what', of being an Architect are based on the structures they follow, such as Governance, Design and Assurance they tend to be common in nature, whatever the industry or the subject. Conceding that the detail in the activity is different, such as whether the design or business subject is Telco, Financial or Marketing, but detailed knowledge of that subject makes someone a subject matter expert, not an Architect.

Lastly we have the Method, or the instruction set, the 'how' to perform architectural processes. This is the bread and butter of being an Architect, this is the way you think about framing an argument across a variety of stakeholders, or the way you research and collate a set of options on a decision paper.

Applying the above model to being an Architect

So applying the above model to the role of an Architect we can list out several key items that would populate this MetaModel. Note that this isn't exhaustive, but rather an initial set of data, the common things you should really know. This should be treated as a starting guide, a set of terms or topics to make sure that you are at least aware of and ideally able to describe in good detail. I stress this as I've held quite a few interviews for Architects and been surprised how many candidates are not familiar enough with some of these terms to be able to describe them in sufficient detail.

On top of this I've added a section on who would engage in the topics raised here, after all there are several types of Architect, and knowing what they are and what they do is vital to being a functioning architect. Note that these roles are largely taken from the TOGAF model.

Roles

1. Enterprise Architects
2. Solution Architects
3. Service Architects
4. Application Architects
5. Data Architects

Terminology

1. Architecture Review Board
2. Governance
3. Assurance
4. Solution Design
5. Architectural views, such as Conceptual, Logical and Physical
6. Building Blocks
7. SOA - Service Oriented Design

Activities

1. Stakeholder Management
2. Review and approvals cycles
3. Decision papers & impact assessment, including things like Change control
4. Stakeholder specific formatting of designs, tailored to their specific viewpoints
5. Architectural levelling, such as 10,000ft view, 50,000 view etc. Used commonly to describe the level of detail a solution is at.

Processes

1. Modelling processes, i.e. How do model solutions
2. Discovery processes, such as how a process, system or application works
3. Documentation processes, such as common MS office based work
4. Options papers, where several options are presented, they are compared and a recommendation is put forward to form a complete argument
5. Alignment to Principles and Patterns - Showing Architectural thinking and alignment to Strategy

I would consider all of the bullet points above as key things to be aware of i

The standard approach to becoming an Architect

Tue, 28 Jun 2016 06:17:00 -0000

Is there a standard approach to becoming an Architect? I'd consider that there is a standard pattern to becoming an Architect, but the individual steps on each individuals journey is likely to vary quite a bit based on drive, opportunity and situations that arise allowing an individual to move forward.

A foundation element in this approach, whatever the specific path, is that the individual works through the existing discipline, rises to the top in recognition and moves up or sideways to gain more experience or responsibility. In this way the individual is building both breadth and depth of experience in a variety of fields. A repercussion of this is that eventually the individual ends out with a broad range of experience across several disciplines. This makes them an ideal candidate to step into Architecture, whether that was their intended goal or not. You can test this out, do a straw poll in your office, how many people intentionally 'become an Architect' instead of 'naturally fell into it after a career in many other disciplines'?

We can model this as:

Breaking down the above image we can see that a common career trajectory into Architecture is via several disciplines. Once a person hits a certain level of maturity in the discipline they currently in, they expand their skillset by moving around, or up. As the person gains skills and moves upward each movement becomes harder and harder as the roles gain in seniority, and availability. From bottom to top is a shrinking model of available roles, with each position above typically having a significantly smaller number of positions available at each level. This arrives at an end point with the chief Architect role, which is typically a single role within an organisation.

As above in my intro, this model encourages individuals to gather both breadth and depth of skill in each field. This depth of background experience is one of the key components that allow an Architect to successfully complete normal architectural tasks, such as decision papers and end to end solution assurance.

One element of this that is especially true is an Architects ability to understand all the different aspects of a solution, and being able to play that solution back in a format suitable for a variety of stakeholders, at their level of view. This interpretation of a solution, played into the Business stakeholders is a key skill for Architects as it allows them to convey often complex, difficult solutions to key business representative in a consumable format for them. This Assurance role gives clarity to the business on the fact that defined solutions are aligning to their strategy, and that the project spend is delivering what they want, and what they think it is delivering.

Think of it as, Assurance requires credibility, and credibility only comes from established, evidenced experience.

The journey to becoming an Architect

Sun, 26 Jun 2016 05:58:00 -0000

A common issue that I see in many organisations is one of resourcing and quality of resource. There would appear to be significantly more demand in the UK market for Architects of good quality, than there are actual Architects out in the 'resource pool'.

Now there's likely a few factors involved in this;

1. Sometimes the criteria for actually identifying what an Architect IS can be a bit vague, and is open to considerable amounts of interpretation, this is across both organisations and Architecture industry bodies.
2. The path to becoming an Architect is typically quite a long one, with an individual having to traverse many different disciplines, gaining experience in each, and practicing a set of 'over the top' skills as well, such as stakeholder management, to be able to operate in quite a demanding space within an organisation. This is generally not a fast process, taking time and effort, becoming familiar with a lot of different challenges, being tested in them, and becoming a pretty resilient character.

So if you've got aspirations to get into Architecture, how do you go about it? What's considered the 'traditional' path? Is there a fast track? All things that I'll cover in a series of blog posts. Its going to be a pretty big picture conversation, so

I'll link each one off from here, taking an Architectural approach if you will, building up each part of the story so that you can see how it comes together. Note as well that this isn't a guide to TOGAF. There are much better places to learn that than here, I'm simply applying some of the core elements of the framework to show how it can help you think about being an Architect. TOGAF may appear somewhat 'High brow framework' sometimes, but it has been developed over the years with a common sense approach to how to actually perform Architecture tasks, as such it can give us some really good insight into how to think like an Architect.

My initial list of topics is below, but as is the case with any Architect, I'm likely to change it as I go along.

1. The standard approach to becoming an Architect
2. Is there a fast track approach to becoming an Architect?
3. What do you need to know, to become an Architect?
- a. Architecture roles
- b. Architecture domains
- c. Facing into a Business as an Architect
- d. Common 'approaches' (get out of jail free cards) that Architects use
4. What should you be able to knock out the park, day after day as an Architect?
- a. Options papers
- b. Transitional state views (AS-IS in comparison to the TO-BE) typically showing Tactical decisions and whether they align to an overall Strategy
- c. Governance submissions and responses
- d. Conceptual, Logical & Physical architectural views
- e. Principles and Patterns

Think I'm well off the mark in any of these articles? Feel free to provide a counter balanced view, after all, that's a key aspect

Blog of Shaun McCran - Architecting robust, elegant technical and business solutions

Adventures in Lego: the UCS Millennium Falcon (75192) – post 4 - bags 9-12

Adventures in Lego: the UCS Millennium Falcon (75192) – post 3 - bags 6-8

Adventures in Lego: the UCS Millennium Falcon (75192) – post 2 - bags 3-5

Adventures in Lego: the UCS Millennium Falcon - 75192 - unboxing

A career change, a blog hiatus, but I’m back to it now

How Swindon Inchcape Audi destroyed my faith in the brand, and that specific dealership

Examining Leadership: Retaining your talent

Why should you invest in Architectural qualifications?

The Individual view

Corporate view

Industry view

Types of Qualification

TOGAF

BCS, Enterprise and Solution Architecture

Further reading

How good is your recruitment and joining process?

The recruitment and joining experience, more important that you think

It's a maturity barometer

Recruiters, treat your role advertisements as if they were first dates

Conceptual, Logical & Physical views of solutions

Conceptual, Logical, Physical architecture example

Is there a fast track to becoming an Architect?

What should they be tested against?

Subject matter experts

Architects

Flexibility and not detailed knowledge

What's missing from this process?

What do you need to know to become an Architect?

MetaModel for a professional role

Applying the above model to being an Architect

The standard approach to becoming an Architect

The journey to becoming an Architect