Control Services in ArchiMate

Control Services are a mechanism we can use to implement security control measures. I wrote this blog to demonstrate that controls are real things, which we should carefully consider; not just line items on a spreadsheet.

The Common Understanding Of Controls

I’ve seen very varied levels of understanding on control measures.

The most crude level of control implementation I have seen is where a project just runs through an excel with a list of questions. For example, they will simply ask the question “is the web server traffic authenticated?” and a technical person says “yes”.

That’s not really a control so much as it is a check of the current state. Some people argue that the exercise of running through the checklist and answering those questions is a control – and to a limited extent I can except that; This basic checking is better than no checking. However, There are varying levels of control, I tend to think about controls in terms of continuous control.

Its important to note there is a balance to be had; In designing any solution you need to think about your requirements, and you need to think about effort, vs return. Its just as easy to over engineer things as it is to under engineer them. Every now and then when I am designing something I stand back and ask myself – is this too much?

The subject of fully modelling security will take a few blogs, and wont try to cover everything here. A lot can be said around FAIR / SABSA way of doing things. There’s a whole bunch of related concepts and elements that I am not covering here.

The Control Measure

Figure 1 – Realizing a control

There are many frameworks out there that have security controls – for example the Cloud Security Alliance has the Cloud Controls Matrix. When representing a control it can be modeled in standard ArchiMate as a Goal element. Those of us using BiZZdesign’s Enterprise Studio (BES) have a set of elements especially for risk management – so we can represent them directly. In our example we are going to use a fairly simple control – Authentication – a standard control that exists in any number of frameworks. Figure 1 – shows how a control service realizes a control. In BES security controls can be modeled in figure 1.

For those using BES, Control Services can be created in a risk and security view. Although that view type only has a few elements in the create window, its possible to paste architecture from other views into a risk and security view. Enterprise studio will also allow you to assign a control strength to a control and has a number of features relating to modelling risk and security. Control services in BES – have a padlock next to them.

Showing a control service within your architecture

Representing a control service as part of an architecture model is easy. so as an example if I created my Authentication Control Service you could see it represented on a diagram like this:

Figure 2 – Implementing a control service

In this case I have associated my service with some application components. Already this beats the approach of just saying “yes, we have authentication”. Its showing how our controls are implemented; we can see exactly where in our architecture our control is enforced.

Designing a Control Service

The authentication control is a simple example, but right from the beginning I can ask some simple questions:

  • How do I ensure that control is being continually achieved?
  • What do I want to happen if things fail?
  • How much of this control can I automate?

I was talking to a colleague about implementing this kind of a control in a conversation in the office and I came up with something like this:

Figure 3 – A control service

Figure 3 was a quick view drawn to support a conversation, during a conversation. Its not a complete architecture but it does show some elements we can use to control authentication at an application layer. This control would be fairly easy to scale because it doesn’t rely on any person to check it. It leverages policies in active directory, and in this simple example I was demonstrating that we need a mechanism that shows continuous control.

You can see I was showing that we do not just need an authentication mechanism but we also need a mechanism to ensure its applied – you can have the best burglar alarm in the world, but if you don’t switch it on, its useless.

The view doesn’t cover all the IT Aspects; In itself it raises other questions we would need to answer in other views; for example:

  • Where would we run the different application components?
  • Who supports this architecture?
  • How would it be deployed?
  • How are these things supporting business needs?
  • What are the motivations for this?
  • What are the Key Performance Indicators & How Would I Implement Them?

In my example I am showing an application level control service – I can also have business or technology layer control services. There’s also nothing to stop me realizing a security control with a number of different control services or a combination of them.

So Why Bring All This Up?

Controls are important. The point of this blog wasn’t so much to show how to properly design a control service, as it was to show that there are varying levels of control you can apply in architecture, and hopefully to get people to think more seriously about what applying a control actually means.

I have spoken about requirements realization before – I tend to think of controls in a similar way – it is not enough to say we have controls in place – we need to understand how we have controls in place.

Controls need to be considered as an integral part of architecture design, and should not be an afterthought. If you design controls into architecture audits become significantly cheaper, because you do not need to burn so much time hunting for answers to auditor questions – you are continuously ensuring a well designed solution which does not only satisfy the needs of the auditors but is also built to actually protect the Information running through our systems.

Keeping Promises To Customers

Its the most natural thing in the world to want to promise things to customers to keep them happy. This blog discusses the dangers of that.

There are a couple of scenario’s I have seen occur many times in my career. Sales and customer teams unintentionally causing harm while wanting to keep customers happy.

Keeping Promises – The Catch 22

There’s a circular downward spiral that can happen:

  1. Teams have trouble meeting customer expectations
  2. To make customers happy they make promises that are hard to keep.
  3. Because those promises were unrealistic, they loop back to step 1.

Its very important promises made to customers are realistic and can be delivered. For Example, If an architect says something will take 20 months to deliver, Its for a reason. A customer team should not agree with the customer to deliver in 12 months, without the solution design being revised.

Its important to re-plan because its most likely not as simple as throwing extra resources into a project or working overtime. Although efficient architecture can make scaling resources for projects a lot more cost effective, often architecture designs aren’t perfect which leads to a cost overhead. There are often dependencies at work. For example if an architect says migrations will take 2 week that estimate may have factored in things such as the amount of data that needs to be migrated and transfer speeds between systems.

If the customer needs to then do things in one week – the architect has to be consulted. It may be possible to meet the deadlines – but, for example, it may mean changes to the solution. Upgrades of hardware would mean extra costs, a different plan, or another mechanism for transferring data. Maybe using disks to transfer rather than over the network is an option. If you change the transfer mechanisms other risks come into play, and the impact on the end user may change.

Somebody Else’s Problem

Sometimes I have seen it where a the delivery team are just not consulted by the front facing sales or customer teams.

People are motivated to meet their own targets, and sometimes targets and goals for individual teams do not factor in a need to work together.

For example, a sales team may have annual sales targets. This can motivate them to make promises without considering the delivery consequence. If you measure and reward a team based on getting customers to sign they will do what it takes to achieve that.

It is a very different case if metrics are put in place to tie together the success of a sales and delivery team.

Adopting A Culture Of Collaboration

If a sales and customer team makes unreasonable promises, it will ultimately cause harm in a few different ways.

  1. Failing to deliver erodes trust; conversely becoming a trusted partner really opens up doors of opportunity.
  2. Putting delivery teams under excess pressure destroys morale – bad morale destroys productivity and you end up with long running projects that have very poor retention of staff. At this point if you don’t have good architecture in place your costs can also skyrocket as unnecessary meetings and fact finding missions start to happen as people need to catch up and be on-boarded onto a project.
  3. Costs also start to balloon because its likely that you end up customizing standard solutions when you don’t need to.

Its very important that sales and customer facing teams collaborate with architects. Don’t forget architects are there to solve problems, not create them. If a sales or delivery team is going to ignore or override what an architect tells them then that’s likely to have consequences.

Summing it up

A good architect designing architecture should be considering the needs of all the stakeholders and identifying risks to the different stakeholders as they happen. They are not there to make the life of the sales or customer team more difficult – although sometimes it can feel like that when they are pointing out lots of potential risks. There are internal risks of course that we do not expose out to customers, but its good to have an honest opinion.

There’s no shame being in a meeting with a customer and saying “I understand your needs, but before I commit to these deadlines I need to talk to my architect team”. There are sometimes times when sales need to agree to things to win a bid – but they should still talk things through with architects. Sometimes seemingly small things can significantly impact the viability of an entire business deal

I will end this blog just mentioning the importance of engaging architects all throughout a project. You do not want to leave architecture to the end of a project.

10 Issues In Implementing Large Scale Organization Change

This blog details 10 issues I have experienced in the past when organizations I have worked for, or with, have implemented large scale change

Recently the Company I work for Tieto announced a merge with Evry. We will become TietoEvry. Over the years I have seen many mistakes happen in different companies making large scale strategic or operational changes.

I would hope our organization avoids these issues in the run up to our new merger and I would hope anyone considers before implementing large scale change.

1. Planning Strategies

All too often I have seen big changes happen without proper planning; management have an idea, may have a few focus groups, or get outside consultancy and a new direction is born.

The big mistake can happen when this is done without fully understanding the impact of change, which is where enterprise architecture comes in. We have a whole range of skills around understanding business motivation, and analyzing business risk and change. Our modelling techniques when properly applied can enable us to help management understand the true impact of change. A good Enterprise Architect can act as the right hand of the business stakeholders.

If you build a strategy without involving enterprise architecture (and this does happen) then you may be limiting its effectiveness. You may be implementing an inefficient plan, or in some cases even an untenable one.

Its important to involve enterprise architects at the beginning of any planned organization change and throughout it. A good EA has tools, and insight into the change process and can provide all manner of methodologies that can help.

2. Solving the Big Problems

Before releasing a major direction change for a company its important to have solved the big problems – and to have a plan not only on what you want to do, but how it is you want to do it. In defining the plan to move forward its important to at least have a partial idea of where you are – understanding the current state helps you understand how to move forward into the future.

I previously wrote on planning work with Archimate – Fundamentally the concepts I introduce could be used, but with large scale change its important to start building strategic layer thinking. I would define current and future state architecture as well as the transition between them – in ArchiMate terms this would be defining plateaus and plenty of implementation architecture. The time you spend planning ahead of time is small compared to how fast you can burn time when nobody in the organisation has clear direction after a strategy announcement and just waits and sees what will happen.

A good approach is rather than just announcing change and stating it will happen, engaging teams before hand and get them to help. Taking a conversation where you say “We are assessing a number of options – if we take this option, what would be the impact to you – and what would we need to do to make it work?” will help you see pitfalls that may not of been evident and it also gives a level of engagement and commitment to an idea.

When merging companies, or making changes that will have major impacts on the jobs of employees, there are of course some limitations to how far you can take such an approach. Even if you cannot engage the entire company, a good enterprise architect will help.

3.The Aspects of Architecture

I have spoken about the IT Architecture Aspects before. As with all architecture changes, a new strategy necessitates us to think of our architecture aspects:

  • Processes & Roles
  • People & organization
  • Information & Governance
  • Tools & Technology

For each of those areas we effectively need to explore what, why, who, how and when. This can be approached with different levels of methodology. Some EA’s model these aspects using languages like ArchiMate and are able to give detailed analysis of the impact of change across the different aspects. Its very easy to miss key elements when you are not thinking about how the different aspects interact with each other.

4. Feeling Engaged

Its important for teams to have a solution minded approach to issues, rather than a problem minded one. I have to be careful with this one myself; I tend to think in terms of problems – not because I am negative, but you do need to identify a problem in order to be able to solve it. If a team has a problem the same team should also think about potential solutions, or we can handle it as an architecture concern.

Its amazing how a few individuals can derail the success of a strategy. At one point I started running a new architecture team that was implemented amidst many other changes. In order to manage the scale of change I decided I needed to engage a small core team of 5 architects and they would manage the larger team of around 100 people. I was distributing authority, because I am only one person. My plan would have worked well, except for one person. I would set direction for my team on a Monday morning, and in the afternoon the core team would set direction for everyone else.

What happened was one person in the afternoon meeting would complain about everything. Effectively that one person turned the entire strategic focus from being solution oriented, to being a firefighting one. It was negative and it was hard to get people engaged in creating a positive change. My core architects were stressed and every little thing then began to be questioned. Even more time was wasted.

In the end because I had to manage that problem and for a while my work was significantly increased. I didn’t allow this to continue for long, but my point is, that if I had known the trouble spot to begin with and taken efforts to get that guy on board with the new strategy, the strategy would have been faster and easier to implement. If one persons argues an hour in a meeting you invited 100 people to – you have lost 100 hrs of time and will have collateral damage.

There’s a balance to be had. Where you see a negative influence, you need to deal with it fast – preferably in a positive way. A passionate person can be your undoing, but when you manage to get the same person on board they can be your biggest advocate. Its good if you can identify passionate people up front.

5. Role Management

When I look at different companies and reasons for failure of strategy execution sometimes it can be traced back to Human Resources / Line management processes and adherence to them. Any job role has a set of expectations and those core role expectations are the ones that need to be assessed and measured. When this isn’t done what can happen is over time as the organization changes, roles change. This can give an enterprise architecture headache as you see an organization that appears to be fully staffed in different functions but in fact isn’t. When trying to decide a new team structure this can be a problem.

For example if technical specialists become architects without proper training and assessment you end up with a group of architects who will know technology but not have the skills to be able to fully describe an architecture or manage it. The transformation from role to role may have happened for a variety of reasons.

I once in the past came into a project with over 40 architects, of which none of them could actually describe architecture outside of creating basic technology views in Visio.

If you were to run a team with 100 architects, and you think the workload only needs half that, last thing you would want to discover is that in rationalizing teams you have broken other areas of the organization because the job those resources were actually doing was not what you thought at all. Before making such decisions its essential to really understand what all roles and responsibilities in the organization actually do.

6. Consistency in leadership

For change to be effective it needs to be understood and aligned within the leadership of a company. When a CEO announces a change of course everyone in management normally want to do the best to support it, but sometimes their own personal goals and targets can restrict this. IF a CEO gives a set of goals to hes leadership team the leadership team needs to filter those goals down to the level below them. and that level needs to cascade the relevant goals further down.

I have seen in the past in some companies goals at the top level that look very different to the lower levels. If a board member has 10 goals around growth, and development in different areas, but his/her direct report only has a financial target – much of what was intended will be lost. Even if PowerPoint presentations fly around the place with all the original board goals. Much of what is in PowerPoint gets forgotten over time. The formal review mechanisms need to include the goals from the board in some form; if you are expecting the subordinates to meet them. The formal review process is actually what impacts peoples earnings and career development.

In one company I created an architecture view that showed 5 levels of management together and their goals, and only financial goals existed below the third level. I asked my manager at the time why this was, and was told that the management didn’t want targets that they couldn’t easily measure, because it would impact their bonuses. This was bad.

If your HR processes are clear and measurable, and someone takes the time to ensure that goals are aligned as we filter down an organization then when change comes we can more clearly ensure that change is effective. Wen building a strategy clear expectations need to be laid out to every level of the organization and if need be working practices and processes revised.

7. Unclear HR

People tend to stick with doing what they are comfortable with but unless goals change and people understand their own personal role in a new strategy people will not be fully invested in it.

What can be worse is when the change then happens – often some roles disappear. This is where hero’s are born – and a hero in enterprise architecture is not always a good thing.

8. Heroes

Heroes do their best to mitigate the chaos around them by assuming the responsibilities of roles that do not belong to them and seemingly get things done. I have a love/hate relationship with this. I applaud the effort and intentions. However, this can break things in many ways for many reasons including:

  • Roles informally transform: if a role informally transforms it means you have created a deviation from the intended strategy; and the way the company is something else. Your organization is not running as intended.
  • Processes start to break: At this point you will start to detect the issue if your processes are properly measurable – because you will see they are not running as anticipated; the correct people are not doing the correct things. The outcome may appear to be good but the working practice is unlikely to be efficient, and where you aren’t following process you are likely creating risk
  • Understanding resourcing hot spots becomes impossible, because people are covering them up. For example if a sales team suddenly looses the services of a translation team, they may have people who can do the translations in their own team. If they do that without properly escalating out the fact they are doing that work there are a couple of possible issues –
    • Firstly they might not do the job as well as a professional service.
    • Secondly, they have then become unwittingly accountable for that translation.
    • Thirdly, they have added to their own workload and stress. I’ve seen this break good intentioned people.
    • Fourthly, The line manager may understand this change in role but if its not formally built into the role then in adding the responsibility to the resource means the focus is suddenly shifted from the intended job role to something that is invisible to the organisation on a whole. If that same resource is spending a week doing translations in a sales case, he is also spending a week not doing sales.
    • Fifthly, This isn’t scalable. If a sales resource is bridging the competency gap filled by another missing role in the organization bringing in another resource to assist won’t be as effective as it should. Different heroes will extend themselves in different ways and this becomes quickly immeasurable.

In bad situations I have seen line management become reliant on heroes. If you are a line manager and can only use one or two of your key resources for a specific task the chances are something is wrong. Either your operational processes are broken, or your HR processes are. As a line manager this has to be escalated and actions must be taken to rectify this, or what will happen is over time, you will lose your hero as they become overwhelmed; and you will be left with worse resources, until the quality of work becomes so low that the continuation of business is untenable.

This may sound a little controversial but we need to eliminate the need for heroes. If our strategy ensures we have clearly defined roles and KPIs, and we put in processes to ensure they are followed the need for heroes is significantly diminished.

Its important to be aware that having measurable KPI’s in an organization doesn’t mean you become any less flexible. It means you are keeping track of the things that matter. Its possible to have a good balance of discipline and flexibility.

The professional

I can imagine some people thinking what I said about Hero’s is wrong – because we all have responsibility to do what we can to further business right? Yes we do. but there’s a right way to do it. In an organisation I would say everyone has a responsibility to identify and escalate risk where they see it – I would also say, sometimes we do need to step outside our roles and get our hands dirty when its needed. Of course communication and collaboration is important. Collaborating with our coworkers to help them is important – but we should always be mindful of our own roles and goals, and of the process.

9. The Importance Of Process

Process is important because it enables us to scale, have common direction and measurement, whilst managing risk. Sometimes process is not well defined which needs to be addressed. When a professional escalates they do not normally just complain; its far better to offer a solution rather than a problem. Its also important to have perspective. Everyone thinks that their area of business is important, but its rarely as nearly as important as the business of the whole organisation.

Properly defined business interfaces need to exist between different parts of the organization, and between the organization and the outside world. All these things need to be measurable. If you are running a business with many service areas, as well as the underlying processes, you need overarching processes to hold those units together – not only the company level standard processes, but also processes that address the end to end needs of the customer.

When transforming the organization you need to also be considering from the outset how you are changing process. If a process is not communicated well, is difficult to follow, does not cover all the use cases necessary, or simply doesn’t work, or isn’t helpful these are all failures of process design that need to be addressed by a process team. Processes can be agile and flexible if they are well defined – they don’t have to be a monolithic. Process often gets a bad reputation because its often poorly designed and implemented.

10. Communicating Change

The first thing I would say about this, is do not talk down to your resources. Treat people with a level of respect and intelligence and they will, to an extent, do the same. Of course there are legal implications of what you can and cannot communicate, and over communicating can be problematic too. If you stress people to the point they are worried about their jobs efficiency goes down unless in the same time you are communicating exactly what needs to be done in order for people to keep them. A plan that is effectively designed between management and an EA will go a long way towards quietening discontent.

Having a plan defined with architects before announcing huge changes goes a long way to calming fears. A company can loose many man hours if they announce the change and then do not follow up with direction as to how the change will be handled and implemented quickly afterwards.

The direction “Business as Usual” has a limited effectiveness. Uncertainty is a productivity killer. People sometimes will worry – they will stall – they will be reluctant to implement some initiatives because they will be concerned of effectiveness.

7 Biggest Frustrations I Have Faced As A Lead Architect.

This blog lists the 7 biggest frustrations I that have experienced in 20+ years of working with architecture and some of my approaches to tackling them.

The frustrations I speak of come from different companies I have worked with over that time. I wanted to share these in hope that it helps other people; they are not frustrations I feel now!

1. The Idea Architecture has to be “hard”.

In my career i have spent a lot of time dealing with people who don’t embrace architecture because they see them complexity and not the benefit. It can be a bit overwhelming to the uninitiated. The best architecture is most often simple architecture; or a complex architecture that has been broken into consumable views. Sometimes its perceived as complex to do a formally structured architecture because architects have their own ways of doing things, which are not based on formal methodology, so there is a learning curve.

The more architecture you do, or the more you model with a language like ArchiMate, the easier it becomes. In some cases I’ve seen some architects spending much more time complaining about creating architecture than it would take to learn and do architecture.

To mitigate this I break things down into small consumable chunks. You may have noticed many of the ideas and things I present on this website are often simplistic – or miss some elements completely – For example in Planning Work – I didn’t mention Plateaus or Gaps. This is because when I talk about work planning I want to start with basics to get going. Sometimes you can achieve more by asking for less. Later on once people are more comfortable with some things I may introduce the next layer of complexity.

I give a lot of time in 1 to 1 sessions with architects – and I have a few people I mentor and spar with. To develop an understanding of architecture happens best when you have someone who actually has some experience and can explain not only what we do and how we do it, but also why. Those people I have mentored have gone on to teach many more architects.

2. Stakeholders not giving commitment

This one can be tricky, especially if the managers I am dealing with are ex technical people with a view of how things should be, what they want to do and how they will achieve it.

In immature organisations these guys want to just bypass architecture all together in order to get something out the door, or see architecture as just creating a technical view.

If stakeholders and resource owners don’t understand the value of architecture, and an EA is not a direct line manager of those architects, then architecture doesn’t get done. The consequence can be any or all of the following:

  • More incidents or major issues
  • Poor compliance to standards & huge costs when auditors come
  • Operational inefficiency
  • Poor scalability & automation
  • Poor business agility.

The best approach to tackling this is to show value directly to your stakeholders, by taking a few of their key problems and helping to solve them through architecture. You have to engage the stakeholders directly. At one point previously I had an architecture team and trained them in architecture discipline and had constant trouble with achieving anything. This was because although the architects saw value in what we were doing this value wasn’t getting properly communicated to the stakeholders, so I was never getting enough time commitment from the stakeholders that owned architects to show much benefit architecture can bring. I would say its better to engage stakeholders directly.

3. Business not Understanding the function of an architect.

Sometimes people get the Impression that architects just do technical solutions – which isn’t even true if they are technical architects. There are of course different types of architects with different functions – but in general, you have to understand the word solution.

To build a solution you need to frame the problem. An architecture isn’t complete unless it shows the requirements the solution must meet, how those requirements are met, and then the final solution. Requirements come from all directions – not only from the technicians themselves.

If you aren’t considering the needs in terms of the different aspects of architecture then its very likely your solution isn’t fit for purpose, If you are lucky at this point the technology is fit for purpose, but all the costs and the impacts of the changes haven’t been considered because you haven’t managed stakeholder concerns. When this happens inevitably there’s a cost overhead in communication, and often an additional overhead as we have to change the technical solutions when new things are raised as issues and you have general inneficiency.

Sometimes I have seen the opinion that project managers manage requirements; which is partially true. Project managers are concerned with understanding project status, and to do that they need to understand the status of requirements and their realization. For that reason requirements management may be laid down by a project practice. In organizations with immature architecture practices this leads to project management organizing and managing requirements. This can lead to overheads and challenges for the project managers who then need to start to get very technical to understand requirements realization. If a project manager needs very specific technical knowledge it normally means an architect is failing to do architecture somewhere.

This can be a disaster in large projects because there is an order to requirements and services. I have seen in some cases project managers take requirements and just assign them to different teams then each team takes responsibility for those requirements. This adds can be problematic because when a project manager manages the requirements work, the project is the focus, and not the development of the solution. In large projects this can mean architecture is worked on in isolation by different teams and when the pieces are put together at the end sometimes they don’t fit.

In addition to that, customer requirements and project requirements are not the only requirements that need to be managed – there are non functional security requirements, architecture requirements, as well as requirements from other teams. They all need to be managed together, and an architect ensures this happens by applying architecture discipline.

4. Not having architecture discipline

Doing architecture once you know how is not hard. Its getting to that point that it is second nature that can be tricky.

By architecture discipline I mean giving the time to do architecture things. Architects need to manage concerns, document decisions, and and either model or document things. If they aren’t given time or don’t give priority to those things bad things happen.

Firstly the value architecture brings to the overall organization is significantly diminished. There’s a lot of benefit you can get out of an architecture model. Not tracking key decisions in one place, or tracking how requirements are being managed leads to a huge overhead.

Firstly if someone else is trying to understand whats going on – they cant. It means extra meetings, extra time, extra cost.

Secondly over time we lose reasons why things happen. Architects and other project resources change. Even if they don’t – sometimes remembering why i did something yesterday is a challenge, thinking back to three projects ago a year back, is hard.

A third point here is that we lose the ability to collaborate. Its possible for a group of architects to work together – one on technical design, one on standards compliance, or to break down a project between all manner of dimensions. You lose the ability to do this effectively if you do not document.

Time has to be given to do full architecture, or development work may be inefficient or may drag on for extremely long time periods due to bad scoping.

Many people consider proper architecture discipline to be a pain in the ass, but it is MUCH cheaper than having to waste time correcting things after. Correcting things will take a lot of people a lot of time.

Its possible for good technical specialists to create end to end solutions without practicing architecture discipline. But when that happens you are suddenly reliant on that single resource, and you will find that adding extra “architects” to a project wont help get things finished faster – because the architecture doesn’t scale. The extra resources will have a diminished return because they simply dont have the knowledge of the people in the project and no way of getting it, other than to ask a lot of questions, that they may or may not get answers to.

The only way I manage this is to be clear in my communication with stakeholders. To identify what is needed in terms of discipline, and the risks of not having it.

5. Not having the skills

I’ve spoken at length about the benefits of different things, such as architecture, and ArchiMate. Architects need to understand how to structure and communicate architecture.

A common architecture language such as Archimate is essential. Its not enough to understand what a view looks like, its essential to understand the meaning of each element and meta-models that are being used to structure an architecture. Do that – and suddenly communication can become a lot more efficient and we can start to share and communicate architecture, and leverage some benefits of scalability.

Technical specialists are not architects and shouldn’t be confused. They are really important, but rarely do they think far beyond the borders of technology. You cannot take someone who’s worked 10 years in technology and just expect them to suddenly understand everything about architecture methodology. Anyone who has ever done any fly fishing will know there’s a lot of difference between observing it and actually doing it – even if you have spent 10 years fishing with a reel.

If you want to really leverage the benefit from architects they need to be trained, and they need to be working the same way. In situations where a company has several methodologies a mechanism needs to be put in place to align them.

If you don’t train architects to understand your common languages such as archimate consistent communication is challenging. Its much like putting 4 resources in a room that speak different languages and asking them to collaborate to solve a complex problem. As a Swedish Speaker i may be able to understand a few words of German, or as an English speaker I may have to figure some kind of sign language and resort to a pen and paper. English and Finnish are very different to Swedish and German. I may be able to figure out whats needed and solve the problem, but I may not be 100% accurate, and it would have taken a lot of effort and frustration.

Have architects mentored or trained.

6. Creating Architecture at the end of a project.

I’ve done a whole blog on reasons not to leave architecture to the end of a project. To sum it up in a sentence – when you leave it to the end of a project – its not architecture its archaeology.

Just don’t do this, and communicate to stakeholders the reasons its a bad idea.

7. When you see all above.

Sometimes there can exist a situation where all of the above can exist. When that happens its very hard to lead an architecture team. It can be hard to get management commitment for resource time to do anything because they don’t see the value of architecture. Because they don’t see the value, and they don’t prioritize it, discipline isn’t practiced so the value is diminished. This leads to architecture being left to the end of a project, which effectively kills off most of the benefit.

In these cases all I can say is chip away at the problem one frustration at a time. We need to be close to our stakeholders and to help them understand the value we as architect can provide to them.

Architecture isn’t the enemy of management. Its there to enable management, not place roadblocks for it. It’s only slow and ineffective when its not fully embraced. Once you have a good architecture team that is committed, running common languages, and a good repository, you can start to provide business intelligence and tools to management that can help them in ways that many managers I have met in the past could not imagine.