With regulation such as GDPR being in force to protect our users, properly understanding information flow becomes essential. This blog shows some of the ways we can model information flow.
There are a couple of different ways we can represent information flow that I touch upon in this blog – I would suggest you use the technique that you prefer but be consistent with it. I don’t normally use more than one method in a model package, unless I have a specific reason to do so.
Using Flow Relationships
I will start with a layered view like have used on several other blogs – our web hosting service serves as a practical example.
The layered view contains both internal and external elements – we will look at them separately. Although Figure 1 shows a layered view I might use to communicate the big picture, as it stands it would need some more detailing before I can fully map information flow.
Mapping Service Flow
In order to properly understand the flow of information between services we need to establish the service interfaces. If my layered view doesn’t have interfaces on – I need to consider and add them. In the example above we have at already done that between the business and application levels – you can see that in figure 2:
The first thing I will do is look at anywhere the interfaces are serving another element:
These areas are effectively where external information flow is happening. I will be looking to replace these serving relationships with flow relationships. In this view i would possibly make an exception though. The service relationship between the HTTP interface and the website hosting interface tells me that there is a relationship between the two. I might normally look further into detailing out the web hosting service to determine how the HTTP interface is used, but in the case of the view above I have answered the question already – its serving the incident management process.
Some architects do not model interfaces against services all the time – myself included. Its dependent on a number of factors; I want to do “just enough architecture”. If we took the interfaces out of the equation we can still map information flows from services to other services.
Considering other relationships
I will also consider the realization relationships in the same way as I look at serving relationships – in this example though I have only an application interface realizing a business interface. the business web portal is only exposing the application layer functionality and there’s no actual data transfer between the layers to consider. Sometimes association relationships should also be looked at.
Putting the flows onto the diagram
Once I have identified the relationships i am interested in I then start to put the information flows onto the diagram. and thinking about information flows. I reorganized the view a little because I decided its not enough to understand which process has access – I want to also understand which role. I then removed the serving relationships from the view, but I didn’t delete them – they are still valid for other views.
The result was this view
I have labeled the flow arrows, but do not forget that each relationship can also have documentation – where you can further specify what that information means. When looking at application level interfaces, I might want to also think about specific ports we use – and I may either show it on the actual view or in the documentation for the relationship. I chose to not show ports on the view above because I don’t want to turn my ArchiMate views too technical; in some cases depending on who your stakeholder is you may want to do things differently and include the port numbers on the labels.
Breaking things down
I broke my initial diagram into two parts to make the blog a little bit less cluttered as I focus into part of it, and that’s ok. In the same way as I have now shown flow between business and application layers, I could do the same between the application and technology layers. To keep diagram complexity down sometimes we break things into smaller chunks. The initial layered view showed how they all fit together at the highest level.
Doing this information flow exercise highlighted some design issues. The second I came to create a flow from website support to the HTTP interface I realized I should be using HTTPS. I could either change that element (which effects the whole model) or I could establish a second interface.
Because in this modelling exercise I am focusing on information flow between elements other issues come up too. For example – when I am looking at the website support role – I ask myself the question what if the HTTP interface into the website application service isnt enough to diagnose a problem? In the old days I might add an Remote desktop Interface – but if I am using third party cloud providers to provide the underlying service this might not be an option – instead I might define a separate special admin interface.
These questions came up just through looking at the information modelling on a layered view. Information flow could also be shown on a whole range of other views. When you actively focus on different component parts of the view and their relationships, thinking in terms of what kinds of relationships fit and why, we quite often see new things.
Associating Passive Objects
Figure 4 could have been written another way:
Here I created some passive objects – (Business objects & data objects). Doing this has an advantage over flow relationships – if I am reusing elements in different views then I can easily get an understanding for example where Admin Login Credentials are used throughout my model.
You may have noticed I have web pages as a business object and an data object. That’s because conceptually in the view they are at two different levels. at the business level web pages are a concept, but they are made more tangible at the application layer.
Another important thing to note is that some of these relationships do not denote the direction of information flow. For example – the HTTP interface is Serving Website Support – this does not mean that admin credentials are flowing from the HTTP interface to the website support role.
I can easily add Locations to my view to make it a bit more complete from a GDPR perspective:
Normally those elements are orange, but for me that’s a complete aesthetic color clash so i changed it. There’s nothing in the ArchiMate rule book that says you cannot do that!
Modelling Internal Information Flows (and Application Cooperation)
In the same way as we can show information flows on a layered view we can do the same thing on many other views – such as service realization views, technology views and so on. Remember sometimes we might want to have two viewpoints showing the same things in different ways for different stakeholders. We might have a normal service realization view, and one for GDPR compliance work. We can use exactly the same approach as i showed on the layered views with most other views. I would take copy of the view and start removing relationships from the view (not the model) replacing them with flows.
With regards to application cooperation views, they can be done at different layers of detail dependent on need. the best application cooperation views include processes, events, interactions and services. They do not include interfaces and are internal views. As a bare minimum I would expect to see interaction between application components and the services – as an example:
Figure 7 doesn’t really show the cooperation! I am focusing on data flow rather than any causal relationships and elements. This works as a starting point. I have seen some architects do variations on figure 7. Some people like to emphasize the more important information flows.
Other architects do not include what they consider to be less important flows, and produce more abstract views. For example the web page request – is a good example of low level communication that is essential to a low level view but may not be important if we are trying to provide stakeholders an overview.
Personally I like the level of detail in figure 7.
Using Access Relationship.
Where accesses relationships are possible within different views they should be used if those views are for presenting information flow. The access relationship is a data dependency relationship in ArchiMate. its indicating that a process, function, interaction, service or event does something with a passive object.
Using The Path
The Technology layer has an element for representing flow of information – the path. Take a look at figure 8:
You can see here I have represented the path information takes to get from the web server to the end user by creating a Web Data Transmission path. Note that the two end points are not considered to be part of the path. This is because the path denotes to path from end to end – when we reuse the Web Data Transmission element we are likely to want to use it to convey transmission from many different end points.
Summing it up…
Most views can be remodeled to include information flow, and going through the process of doing so will enhance your understanding of information flow and risk.
I focused mostly on business and application layer within this blog but the same practices apply when working with the technology layer
When doing High Level Design Work as a minimum I like to see either the basic information flows in the application cooperation views, or information flows in the layered view.
Having these information flows enables us to ensure compliance to different regulations and gives us the ability to do some very cool things with risk management.
High level design is a subject of much discussion in pretty much every organization I have worked with. The question “How Much Is Enough?” is often put to me. This blog addresses this question.
If you ever have to bring a High Level Design (HLD) to me for review – this blog is a good read because it sets a level of both design and review expectations. I promised a colleague I would publish this blog, so it was written in a bit of a rush and I may go back and update it later.
What is a High Level Design?
I normally break architecture down into 3 basic levels
Conceptual Architecture – Is a single view that sets the scope of the architecture at the highest level of abstraction
High Level Design – Is something in the middle. It gives us the answers to all the fundamental questions, whilst normally staying at a level of abstraction from actual technology implementations.
Low Level Design – Is architecture at its lowest level – which can include actual machine and network configurations, and exactly how things are implemented
Its not practical to build designs without putting them into the context of the business. Architecture is about building a solution which solves the needs of our stakeholder. With that in mind there is some related documentation we should have.
A Business Case
The business case is basically setting the scene for what we expect from the architecture. If an architecture isn’t providing a benefit to our business we shouldn’t be doing it.
Bear in mind, this doesn’t necessarily mean that the benefit is profit. Whatever the benefit is, it needs to be stated, it needs to be clearly defined in a way that is measurable and not subject to opinion.
“We need to make a lot of profit” may be a true statement – but “we will make 1 million Euros in the first year” – is a lot more clear.
The business case is establishing the goals, and business requirements. It basically needs to lay out what it is thats being proposed, and the value we get from it.
Basic Business Case Validation
When assessing business cases I am normally looking to see also the reason behind the numbers. If a product states it will make a million Euros per year i want to see the rationale behind that number, and to see that such numbers are realistic. The most realistic cases are based on existing numbers.
If Microsoft reports an 64% growth in Azure sales, it doesn’t mean its partners see the same growth. Growth and profit are influenced by many factors including how fast you can get an idea from idea to realization, and how well your solution can be scaled.
For basic validation of business cases I normally think as TELOS related questions.
A good business case demonstrates the thinking behind the numbers. If it states we need to hit a revenue target then these goals are part of our architecture motivation.
The key takeway here:
If you don’t have a clearly defined business case, then you cannot know that any technical design or service design will be fit for purpose.
A Conceptual Architecture
Conceptual architectures can come in many forms – I am normally looking for a single view in ArchiMate that shows the concept of the business case architecture. I normally am focusing on scope.
A conceptual architecture for a product normally shows the product and the services within it (Like a product view), as well as showing the key application components, or technology layer components relating to the product, as well as the teams that support it, and other related products & dependencies. In product service architectures i am normally showing Business Application and Technology layers, but not showing data or information flows. This is because of how we use conceptual architectures as part of business validation – adding relationships and information flows makes it messy.
In a non product related conceptual we make sure the view we provide hooks into the current existing architectures (services or products normally.
I recently wrote about Architecture Concerns and will not go into too much detail. For any architecture, having a defined set of requirements to validate is essential. This can take many forms (such as User Stories). This could also be done in a set of ArchiMate views.
Basic Requirements Validation
I want to see the following when I validate a HLD:
A set of requirements – which are clearly defined and unambiguous.
Documented evidence of requirements management – Showing how requirements have been managed, and pointing to where in the architecture requirements have been realised.
Considerations from all the stakeholders perspectives. Lets break that out separately.
Consideration of incoming and outgoing requirements – we need things from other teams – for those things we need agreements with respective teams. On the flip side we may also have requirements towards us. If our solution uses monitoring for example, the monitoring team may require a specific agent to be installed on something.
TELOS – As mentioned in the business case phase a more detailed look into TELOS is warranted as part of the high level design to ensure that our requirements consider Technical, Economic, Legal, Operational, and Scheduling needs.
When we talk Stakeholders its very easy to be preoccupied with just the customer or the end user but in reality many teams or people either provide something to your architecture, or require something from it.
ISO 42010 has a good list of potential stakeholders of a system which includes users of the system, designers of the system, owners of the system – the list goes on. As a minimum need to know that an architecture will meet these needs:
Customer – this includes different roles within customer organization – for example the end user cares if they get a easy to use continuous service – where as the person that is buying the service from you wants to be able to show their management how well the service is used, or the value it brings.
Internal Business – around revenue and profit for example. or if its needed for strategic reasons we need to keep tract of that kind of things. Sales teams may also have concerns with architecture.
Internal Ops Team – They need to be able to operate the solution the architect gives them in an efficient way – there are normally Staffing, Training, Capacity, monitoring, and procedural related requirements for example.
Partner – If we are using partners a business interface needs to be established with them – a set of requirements together with an SLA is a fantastic way to do this.
Validating the Architecture Model
One thing to note is the old adage “If its not documented, it doesn’t exist”. Its important for all information around your architecture to be stored together. a High Level Design can be produced completely in an Archimate model, or maybe part of a document (I discuss this in Designing Architecture Through Document Templates.
Our High Level Design is telling a story. Effectively all those prerequites we have described are setting a challenge. Its the job of architecture to describe a solution that addresses all the needs of a challenge.
Regardless of if you chose to use a document or an ArchiMate model, or in Word, the story needs to be threaded together in a single solution. There may be multiple parts – such as several prerequisite documents, but they need to be referenced together in one place.
Within any solution or service design there are normally many meetings, and its essential we track decisions that are made in a single space that is available for all. Where i currently work i normally track all decisions relating to a specific architecture on a single page so its easy to follow. Its ok to reference external sources for things liike requiremetns or supporting information, but when this is done you have to consider the following
Ensure there is version control so we know what version of a particular document or source we are referring to on our design. normally when i am doing a review meeting i will take a copy of related documents and store them together so that there is a timeless copy that cannot be interfered with
You have to know your stakeholders and ensure they all have access. I have lost count of the times information has been locked up so i cannot see related information.
I also want to ensure as far as possible that i do not duplicate information – its better to refer to master information sources for things when required.
If we are creating an entire high level design in ArchiMate you have to remember to document the model. We are not using our architecture tools to produce diagrams, we are using them to produce views of architecture. Our tools enable us to document the architecture view, to explain what we are showing, as well as the elements and relationships. Remember to address the audience.
Covering Architecture Aspects
Remember just as with our conceptual an architecture has to address architecture aspects. This doesn’t mean i have to address them all in a single place in the architecture – but I do have to ensure that we consider all aspects and not only technology. For example you may address processes and roles in many different views.
A minimum set of views
For those of you that do not know where to start I present to you a minimum set of views to consider. We do not document or create views just for the sake of having them. There may be reasons why you wish to use other views, or deviate from this structure. Thats Ok.
Lets take a look at some of the views I would expect to see. in an archimate model:
We will walk through this bit by bit. An ABB is an Architecture Building Block. Normally I prefer to deal with architecture at a service level but there are times where thats not practical. In those cases related architecture may be together in a grouping box which is named something to explain what it is. For example I might have everything relating to application monitoring described (including its interfaces, triggers and processes) in a grouping box named “Application Monitoring”. You would use a grouping box where you might want to represent a group of elements that are cross layer. Some of our application monitoring processes may be business related or technology related for example. Where possible I prefer to use services or functions to ABB’s.
Conceptual Architecture or Layered Views
The order of things I am showing can happen in two different ways. where I work currently normally at the point architecture begins a business person has already got a conceptual idea in their head and want to start there. Our product management teams are used to working in a specific way – I normally have to start by asking what is it they are trying to do, and then when I understand what – I am wanting to understand why.
Conceptual architectures are normally a good starting point when you are in this situation, as are layered views. I normally take a service focused approach to building architecture. Take a look at my Services In Archimate blog – it shows some layered views.
I normally start with a conceptual view and then refine and define services from there. Every Service or function I have defined at the upper level needs further detailing:
It should appear in a requirements realisation view
It should appear in a Service realisation view
It should appear in a implementation and migration view.
I do not necessarily have to see all services defined in their own service realization views, although I often will. As a rule of thumb if i have more than 30 elements in a view i am asking myself if I need to split it into sub views. Again remembering each view tells a story it may make sense to group together several services in the same service realization view if several services are realized in the same way – or if theres another logical reason to do so.
Requirements and Rationale
Working with requirements realization views, my key element of focus is the requirement. Working with motivations views I like to ensure i have the drivers, goals, and requirements clearly defined. other elements just supporting the story of how a need (driver) leads to a set of requirements that will achieve a goal.
In my Planning Work With Archimate blog i talk a bit about creating motivation views for stakeholder concerns, and I also show a level of motivational modelling in my User Stories blog. Those mechansims are good for capturing different concerns from different stakeholders, but the important thing to note here is that we need to align the motivation model with the actual business case.
I already described the order i do things in normally because its the quickest way to deliver some value in my particular case. However, an excellent approach is to start with a motivational view, to create some requirements realization views from that where i figure exactly which services and processes I need to put in place to meet the requirements.
All requirements need to be shown to be managed within an architecture design. If we are working with ArchiMate we do not necessarily need to see every requirement on a view – its ok to group together requirements on the view to make it more manageable:
The above (Figure 3) is OK- if in the documentation for those requirements you link back to a source where those requirements are all managed together – so we can easily see the working status of each underlying requirement.
The important thing here is that requirements are mapped to their respective areas of architecture. Figure 3 showed a very high level view – I would expect in such a case we would also need other requirements realization views to show more detail because although figure 3 gives me a level of confidence that we are managing requirements, it doesn’t really tell me how.
As an example. Consider customer requirements/user stories for our Web Hosting product:
The point I am trying to make is different requirements may be realized in very different ways. There are different ways we could address each of the needs of our stakeholders, and we need to show in the high level design that we have considered them. If we have 100 requirements for an application by all means group them together, and put them in a single element, but only if it makes sense to do that, and you can show in other documentation how each requirement is handled separately.
Sometimes the choices we make do not appear to make sense. For example, if we had chosen to have a manual business process for billing rather than an automated application process. There might be a good reason – like not having resources to do the automation, or maybe the billing is only once a year and a 2 minute job in another system and doesn’t justify the expense. That’s a business decision. Such a decision quite often gets made in a meeting, maybe minuted and dropped into an email and forgotten about. It is vitally important that decisions are tracked in a work log and not just in a meeting; I have seen thousands of hours burned because of a decision not being tracked and then trying to track back with the relevant people how and what was decided. Sometimes people leave positions in an organization and sometimes you never find out why. Its wasted time that can be easily avoided with a little discipline.
Borrowing from TOGAF – Business, Data, Application, Technology, we need to ensure we describe these layers of information. We could do this in a detailed layer view – but I normally break things down into several views.
The Service Realization
Every Service has a service realization view (Several can be part of a single view). This may be small if a service is provided by a third party – because then you are only defining the business interface – but regardless we need a complete picture.
The service realization view is showing how the business layer connects into the application layer. In our web service hosting example, our business service might be realized by two different application components – Apache & Internet Information Server (IIS).The view shows how this service is provided.
In a high level design I don’t expect to see fully defined processes. For the business processes I only want to understand:
What the process is
How the process connects to the rest of the architecture
What events trigger the process
What the possible outcomes of the process are
Which roles or people provide the process
Normally this can be done a lot quicker than actually fully defining a process.
The Technology Usage View
Within the service realization I have identified a number of different application layer items (Apache & IIS) which should exist within a technology usage view. The technology usage view is connecting the application layer to the technology layer. I might have a simple view which shows how IIS is served by a technology device – or the scenarios could be more complex – for example we may be using virtualization.
Application Usage or Cooperation Views
These views are useful for seeing how application elements connect together, and how they tie into application data elements and flow of information, which is a good baseline for work with GDPR for example. If you have data elements in the Information Structure Views its good to show them here if it makes sense to. When looking at HLD’s I normally like to see both of these views – however sometimes I find application cooperation and service realization views have a little bit of overlap when people model these views.
The Technology View
The technology views show how our technology layer fits together. Following our example if we have technology devices for Apache and IIS I would want to understand how they fit together and are connected via a network.
At this point I would remind people we are still looking to build high level designs. I am not normally going down to the point i have IP addresses. Quite often with services we offer them with a variety of different service levels, and dependent on the service level we may have different technology views. For example, our best service level might necessitate us to build a technology architecture that has complete redundancy and multi site. Our lowest service level may be a single server in a data center. Model the common scenarios.
Information Structure Views
These views show basic information structures/taxomomies relating to the architecture. We create structures that make sense in the context of what we are producing. For example, if we are implementing a new service in service now then we need to determine a CMDB structural template, or maybe even a service now structure. We can lay out the relationships between the data elements and can even document the relationships to explain why they exist.
For more complex structures we could of course use something like a UML class diagram – but most of the time the structures I use are simpler. Figure 1 showed a simple information structure in the business layer, but of course we can create information structure views in the Business, Application and technology layers, or structures to show how they are related. Take a look at figure 6
I chose to use a Grouping box rather than create individual compositions to each data object. Depending on how i was going to use this architecture model I might have done it the other way, but we should visualize in a way that makes sense to our stakeholders.
There is a balance to be had. In a high level design we do not want to go to too much detail – Figure 6 has value because in our fictional example it shows our audience the configurations that we will need to support and helps set scope. We can see clearly that we would need to define two virtual machine templates and a standard network configuration for implementing our basic Apache – and we might chose to reuse these elements. The view gives context to some data objects that would need to be defined in the implementation views.
For more complex structures we could of course use something like a UML class diagram – but most of the time the structures I use are simpler. Figure 1 showed a simple information structure in the business layer, but of course we can create information structure views in the Business, Application and technology layers, or structures to show how they are related.
Relating to information structure is information flow. Its important to document how information flows throughout your architecture. I talk about how you might approach this in my Modelling Information Flow In Archimate blog.
Project & Lifecycle
I talk about modelling projects in my blog Planning Work In Archimate. That blog covers the basic minimums I would expect to see in order to understand a project and its road map. It doesn’t cover more complex concepts such as using plateau’s to represent different states of architecture. I will save that for a future blog.
Using Vendor Or Other Reference Architectures
I am fine with the idea of reusing with pride; several vendors have standard reference architectures. Just because a vendor has a standard reference architecture or a standard set of best practices, it doesn’t mean our job is done.
We still have requirements that need to be realized and we still need to cover the architecture aspects when using a vendor architecture. We also probably need to establish a proper interface and set of requirements for the vendor.
Summing It Up…
Theres a lot of things that go into any architecture design and this is only one approach to creating one. The reality is, that depending on your requirements the amount of emphasis you put into different areas of architecture radically change – for example if we are using Amazon Web Services as a provider of our technology platform we might not need to fully define that platform – although it may still need a small amount of architecture – just for us to state we use the technology level services from Amazon, and maybe what the interfaces into those services are. There could also be related requirements realizations needed of course.
I’ve done my best in this blog to address a fairly complex subject in a relatively short blog. The approach in the blog isn’t perfect, but its one I have developed and used over time to meet the requirements placed upon me by various stakeholders.
Implementing a High Level Design, as described here goes a long way towards creating a solid design that mitigates risks and significantly reduces cost to business.
One of the most essential but often overlooked views to have on architecture is requirements realization. This blog explores this subject and one way we can work with them.
I show one way of working with Requirements Realization Views – Its not the only way. Doing this can save huge amounts of time and money by avoiding a need to redo things.
If you have read ISO 42010 the International standard for architecture description, you will know that every architecture view is intended to frame the concerns of its stakeholders.
Architecture isn’t about drawing pictures. Whist defining a view of technology is important, it is more important is understanding the reason why. We learn this in math class as children. The answer to a math question gives you points, but you also get points for showing work.
The Requirements realization view is one way to show how a solution meets the needs of its stakeholders.
I show below some example views and one way of working that can be used with BiZZdesign’s Enterprise Studio. Its the tool I use most often, so I leverage some of its benefits in my workflow. All the things I show can be done with other tools, some tools make this easier than others.
An Example View
The example above is a basic requirements realization view. Its at a high level – its showing that a product is meeting several requirements. The level of detail we go to depends very much on the benefit it would provide. The view in figure 1 – may serve as a good introduction to anyone wishing to understand the design from the Web Hosting Product. For the purposes of a high level introduction to business stakeholders that might be enough, but how do we know what is above is true?
The next level of detail
Each of the requirements in figure 1 is obviously a collection of other requirements – I might define them in architect, or I might just reference another source. For example – business unit requirements may exist and be managed in a system like Confluence. This might be a more accessible place for stakeholders to manage them if we do not want to go though the trouble of teaching everyone ArchiMate.
The next level of detail in ArchiMate
Personally, I do not always ask for everyone to go to the next level of detail in ArchiMate, because in a complex project with many moving parts it doesn’t always make sense, especially when you have different architects at different levels of maturity, especially when you have several thousands of requirements in a project
That said, there are advantages to mapping your requirements in Archimate. I know one or two architects that do it.
Using Enterprise Studio
Here tools can set you apart. Importing requirements from excel into an architecture model can be fairly easy in some tools. I am using BiZZdesigns Enterprise Studio (BES). – which makes it easy to import and update requirements if I create them using New > Multiple – I can then copy and paste in from excel. I could have done this other ways too and its probably worth the time taken to do that.. You end up with a lot of requirements on a view like this:
You might think in this case that this isn’t very helpful – its just a bunch of numbers – but what i did was import the requirement ID’s as names and I put the actual descriptions in the description or documentation field. In this way when I have many requirements I can make them smaller and more manageable on screen.
To actually see detail of each requirement I can switch on tooltips – so the documentation pops up when I mouse-over the requirement, or I can use labels.
So why bother?
Once I have the requirements on my canvas i can group them together – to organised them in different ways for different stakeholders. Something like in figure 4:
When I have done the above in big projects I have sometimes identified requirements that are not managed at all. In the example above you can easily see uncategorized requirements. They are not connected to anything and can easily be forgotten. Just by itself it makes the pain of the exercise worth while. I can also at this point prioritize them and then I normally take these requirements and connect them into a series of implementation and migration views.
Every requirement needs to be realized some how. I can pretty easily either script, or create a property table in Enterprise Studio to see requirements that are not realizing things as an extra level of validation. If we have mapped our requirements into groups, and created views for each group, then we should easily be able to see things that are not realized anyway. Back in figure 4 we did our mapping, and as a result of the mapping for example we may have decided to have 5 realization views:
Customer Requirements Realization View
Architecture NFR Realization View
Security NFR Realization View
Business Unit Requirements Realization View
Orphaned Requirements Realization View
Mapping Requirements to the Realization
Now with the prep work completed we get to the important part. Our Customer Requirements Realization View might look like something in figure 5.
Lets look closer at figure 5.
The standard web hosting solution
I make use of the grouping element in ArchiMate to represent architecture building blocks. Its enables me to keep things neat – I could have course have hidden this level of detail in another view & just connected in the Web Hosting Product. In this case I felt the services create value. I do not need the detail to know exactly which servers are being used but I can tell that this will be an Azure hosted solution, running on Linux. If you read my blog on services, you should at this point start to see the value of hiding architecture behind the externally facing services.
Standard Services Contract
Some requirements are covered by our standard products and some by our standard agreements. To use the ISO 42010 language again – Its important to see that concerns are all framed within one or more viewpoints. This means even if its obvious to us that something is covered in the standard contract we should state it. What is obvious to me is not necessarily obvious to a coworker.
Of course I could put as much or as little detail as I need into this view. I am telling a story, which I talk about in my Improving Archimate Modelling Blog. The important thing to remember is that all requirements need to be realized in a view, but again not always the same view. Because we are telling a story we need to be consistent with the level of detail.
Locking Down Requirements
Before starting requirements realization its important to have requirements management under control. Its a separate subject, but you need to ensure that requirements are not significantly changing during a project, or the workload significantly increases.Going through the process of redrafting your realization view will provide benefit and avoid confusion.
Some Common Challenges
I have sometimes seen requirements realization being missed as a step. Sometimes people just create a technical solution, and say “yes” that meets the requirements after a first read through, Then later they realize it doesn’t because they didn’t look to this level of detail and are forced to go through a very expensive exercise of fixing things.
I have also seen things mess up because requirements management is seen as being a project managers job. Yes, those guys are responsible to ensure requirements are met, but not how they are met. I see the job of organizing requirements in a way that makes sense to the solution as being an essential part of an architects job. If you look at the TOGAF ADM for example you will see requirements management at the heart of everything..Its partly a separate conversation but I would also encourage architects to work with project managers to organize requirements in a way that makes sense, because it makes requirements realization a lot easier and reduces risk,
Another common issue if focusing too much on customer requirements. Its really common for organizations to have a customer first approach – but this doesn’t mean we should not consider our own needs. Business requirements are important, as are the architecture and security ones for example. If we do not consider them, issues will occur later – because they are there to mitigate risk. Some non functional requirements will relate to documentation and I can easily create a view for architecture deliverable requirements realization. In projects architects should ensure time is given to manage non customer requirements.
Summing It Up
I cannot stress the importance of doing requirements realization. In this article i focused mostly on doing requirements realization in ArchiMate, but we can actually do it in other ways. I wrote about the challenges of Designing Architecture Through Document Templates before – I personally try to avoid that for the reasons I state in that blog.
Requirements show us “what” needs to be done by “who”, and “when”. Requirements Realization shows us “how”. This is a message I think all architects should take to heart and communicate out to other stakeholders.
Yes, running through thousands of requirements can be boring but taking the time to properly manage and realize them can result in very high quality work. Requirements Realization can be cool.
Services are very important parts of the ArchiMate modelling language. This blog shows some ways we can represent and utilize services.
The Difference Between A Service And A Product
Its important to understand the difference between a service and product. I have seen in many places those terms have been interchanged. Product management must have a common understanding to architects, although this doesn’t mean we necessarily need to expose ArchiMate to Product managers. The whole point of ArchiMate is to provide a common modelling language to enable clear communication.
A product is a collection of services and a contract. A product element lives in the business layer. Normally we connect our services to the outside world through the business layer.
Products are composite elements that aggregate or compose any of these elements in archimate:
A business service represents an explicitly defined exposed business behavior.
Although services are also defined in the ArchiMate Manual I don’t think it does them justice.
In point of fact all services are explicitly defined exposed behavior; be it a business service, an application service or a technology service. These services are very important in large organisations. Take a look at this layered view. Its a typical layered view used to show how the Business, Application and Technology fit together for a fictional web hosting service.
It doesn’t show a complete picture – because of course actors and processes in the business layer are likely to connect into the other layers. We do not have to put every element on every view – we use what we need to tell a story. To work more directly with services we can abstract out from the view above:
In figure 3 we are showing only services, and its important to understand the relationships here, and the concepts. You can see A platform service is realized by either Microsoft Azure or an Amazon Web Service. I could have said they were both specializations of a platform service. I prefer to do use the realization because it would have meant drawing specialization relations in the opposite direction which isn’t as intuitive to read.
In Figure 3 the platform service is abstract. We only want to represent just enough architecture. Azure & Amazon Web Services have commonalities. They use virtual machine managers, and virtual hard disks to realize virtual servers. You can see this in figure 4:
The technology view is showing a number of things. If we had not abstracted to convey this information we would have to create two separate views – One for Microsoft Azure & one for Amazon Web Services. We want to avoid this.
Having that level of abstraction makes it easy to add a new technology service and enables us to be flexible. Lets modify figure 3.
You can see we added Google Cloud and System Centre. Rather than having to create two additional technology views, we need to do nothing, because we have defined the platform service in figure 4.
Over Engineered Products
In big organizations its very easy to get to a point where you are over engineering. In the examples i have shown so far I have been showing a single business service (web hosting service). You can see, that regardless of which platform is used, or which technology, we still only need a single business service, because what we deliver is the same.
In some organizations the product portfolio can be overly complex. For example I have seen limitations in financial models which have lead to breaking things down into products where perhaps they should not be. In Large organizations different services are often provided by different business units which can mean that because of the different units having different levels of responsibility, products might be created in each unit. Something like this can happen:
Because product management processes tend to specify a need for business services we can end up having to unnecessarily create products and business services. This can be a huge cost and complexity overhead. All services need established interfaces, all products have their own team of staff, and services need interfaces defined between each other.
Figure 6 could have existed in an undocumented way. Drawing a view like this makes it clear where complexity exists that does not need to and is one way an EA can show value – reducing unnecessary services and better defining interfaces between the services at the different layers.
When we have taken away the detail and drawn our services like in figure 5, it becomes significantly more easy to figure how we want to bill things. If we start from figure 5 we might end up representing our pricing components as below
Back in Figure 2, we showed some interfaces. At a business level our website hosting service is accessible via Email or Web Portal. The Web Portal is realized by a application interface (HTTP Interface) into the website application service. In this case what we are saying is the business service does nothing except expose out the application services.
In the examples I have shown its clear that interfaces should exist for some of the services. that I haven’t detailed in. When I create a layered view I am typically picking and choosing elements, rather than using all connected elements to a service. Other views, such as service realization views, or application cooperation views may show how these interfaces to services exist in more detail.
Functions are internal behavior units that we do not expose to the outside world. In figure 4 we showed how a technology service was realized. Such a view may have been created by our internal platforms team. The Virtual Machine Manager Function might be very important to talk about to that internal team but would not be something that the sales or product development team need to talk about. If we were to need to relate the virtual machine manager to another team, then we would have created it as a service.
Summing It up…
In future blogs I will be building a lot on the usage of services, because there’s a huge amount that can be done with them. This blog only scratches the surface. Services can be used to reduce complexity and make architecture more light weight and agile. They enable us to focus our architecture efforts. If you are practicing any kind of large scale architecture they are essential.
TELOS is one of those handy acronyms we use for validation and checking we haven’t missed anything in architecture. This blog introduces TELOS.
I use TELOS quite a lot when reviewing architecture. One of the reasons why an architecture review with teammates often looks different is because when we ask questions on architecture what tends to happen is some of our lead architects run through TELOS in their heads – and focus in on areas where things need a little bit of attention.
We use it whenever we are looking at investment proposals, or we are presented with architectures or any kind of feasibility study.
Breaking it down.
TELOS is short for:
Some of the questions we ask can technically belong to several areas – such as a question “have you considered software licences for the servers?”. It doesn’t matter if the question is asked as a Technical question or a Economic one – the important thing is that questions are asked. Lets explore this this one part at a time.
This is things relating to technology. it can include things such as technical requirements, skills, capacity and other things relating to the fitness of the technical solution.
Some typical technical related questions:
Do we have the required software?
Do we have all the required hardware?
Are we reusing existing technology/competency wherever possible?
Do we have the skills we need to use the technology or will we need to train or get skills in?
Will we need external collaborations/have third party dependencies?
Will the solution defined meet initial performance expectations?
Will the solution defined meet mid term usage / functionality expectations?
Ive found in the past that its typical to not fully consider your skilling and training costs. I also think that capacity planning is also an area that often requires attention. Many times i have seen a positive problem occur, where a platform is implemented, costs and a return of investment are declared but the actual platform doesnt have the capacity to provide returns that are promised.
Its also important to think lifecycle of the solution and all its components. We need to have an understanding of how long technologies will stay relievent. For example if a software product we are using is several years old and a vendor is known for releasing new things every 2-3 years, will the solution realise its goals before we need to make further changes and incur more costs?
Relates to economy and includes such things as profitability, revenue tarkets and break even points.
Some typical questions might include:
Are all the costs defined?
Are all the revenue streams defined?
Have efforts been made to provide the most economic design?
Will there be an adequate return of investment?
How long will it take to show a profit?
How expensive is the solution? is it too expensive?
Is our pricing competitive?
What is the costs of any potential risks we see?
There are lots of mechanisms out there that can be used to help model and design a proper business case. As a minimum when looking at investment proposals I like to see a Business Model Canvas defined, because you can quite clearly see both costs and revenue streams. Of course not all architecture has a goal to provide financial value.
When looking at a promised return of investment we are looking for the reasons that justify things. Its not enough to say a product will return a million euros in the first year – we need to understand why – which raises further economy related questions
How big is your target audience?
What is the potential revenue for us of everything in the sales pipeline?
How often do we win these sales cases?
Describes things relating to legal.This can include ensuring we adhere to local law, EU Law, or any industry regulation, or contractual obligations.
Typical questions might include:
Are we complying to EU laws?
Have we ensured we are following all the ISO standards and met other commitments we have promised our customers?
Have we considered any industry specific legal requirements?
Some requirements are obvious – such as GDPR because it has such extreme implications and gets a lot of publicity. Other legal requirements are not so obvious. For example we may need to retain financial records for a fix length of time. Its important to ask the different stakeholder of an architecture about any potential legal requirements, so they are not missed.
Relates to things such process definitions, operational needs, lifecycle and change management
Some typical questions might include
Are all of the actors properly defined?
What kind of resources or teams in the organisation will be required?
Will we need to reorganize processes or teams?
Will we need new resources?
Have we made agreements with operations to implement our solution?
Will there be costs in training?
Do we have proper KPIs or automation in place?
Will new teams have to be established?
Will there be staff resistance to the change?
We talked about costs of training and skilling within Technology, but it doesn’t stop there. If we implement a new system or new processes / ways of working we need to ensure people are aware of them. There could also be formally required training, and needs for the building of a communication plan.
We also need to have mechanisms in place to monitor health of our operations so we can adjust our designs as we need to.
Proper architecture design really helps here. Resistance to change should also be planned for because sometimes one negative person can derail an entire project.
Things relating to resourcing such as timescales, road maps and resource availability planning.
Things relating to resourcing such as timescales, road maps and resource availability planning.
Some typical questions relating to this might be:
Given our current expertise are the timescales realistic?
Will the project be too resource intensive?
Will there be availability issues for key competencies?
Are there any timescale pressures that need to be met?
Will the solution be built in time to realize its benefits?
We need to be realistic with our timescales, and resource availability has major impacts on this. If resources are not available a plan should re revised because even with the best intentions you will fail. Time commitment for a percentage of time on a project should be time-boxed. if we have one day a week for a project we need to ensure all resources are available on the same day as part of that commitment, or projects will just drag on.
Key milestones or dates should be defined for things such as launches, and sometimes there are business impacts for being late that need to be understood. For example, when technologies are new the opportunity to sell them might be greater at the technology release than a year later.
A plan or road map should exist to ensure that the project / architecture is delivered at the cadence that is needed.
Summing It Up…
Its quite possible that going through this blog you come up with other questions that would need to be answered in a TELOS assessment, and the questions I have presented in this blog are not intended to be comprehensive so much as a starting point for people who want to start to use TELOS in their working practices.
The questions that I have asked in this blog do not necessarily get answered in a single document – although you might chose to have a TELOS section in a high level design. The questions can be answered in many places in our architecture. A road map view might exist to cover scheduling. A Business Model Canvas may cover most of the concerns we have in economy. Its possible we may cover everything in the requirements documentation or with use cases. Sometimes I have built TELOS into requirements templates, and sometimes I have built TELOS assessment templates. Sometimes its enough to just talk it through in conversation.
Knowing TELOS improves our ability to see potential risks or holes in architecture before they happen