A quick introduction to some rather cool functionality recently introduced into BiZZdesign’s Enterprise Studio.
Note – If you are do not see a Quality tab in your interface, it may be either of these issues:
You are running the wrong version of Enterprise Studio. Its possible to have two versions installed at once.
You are running on a model repository that doesn’t have the latest version of the meta-model schema. You can check this. If you create a new model package and have the quality tab but it doesn’t work when using a team server, you need to talk to an administrator.
Introducing a simple way to do basic architecture work planning using ArchiMate.
In order to keep control of architecture in a complex ever changing work its important to understand the workload. We often have complex projects interconnected, with shifting priorities; architects are asked for many things from stakeholders; to support both our architects and stakeholders I ask for a simple road-map with some supporting views. When a business stakeholder gives new priorities the architect can then easily take an intelligent conversation on what needs to be re-prioritized.
I Abstract away from real work and made up some examples here. So lets cover the Basics; Its far better to ask for basic views using only a subset of architecture elements than to expect fully blown models when you are trying to get a level of consistency and need to balance the levels of complexity with varying levels of competency you invariably face when dealing with a large number of architects.
The Work Package
The key element I want to talk about today is the work package in the implementation and migration layer of Archimate. Work is exactly as in English – its effort that is performed. We define the packages in architecture because it gives us many advantages – In modelling the packages we can accurately represent the effort our teams must take and the impact it has on our architecture over time.
I tend to align work packages to the SAFe methodology even though we are not strictly using it at the moment – a work package is a unit of work that effectively can take 2 calendar weeks or more, and they should be modular; a package should provide value all by itself – rather than relying on anything else. This is important if we are to ensure we provide continuous value over time.
Work can be product related (implementing a new service within a product for example) or it may be related to a specific project or objective – for example we may have a concern around quality of a service which needs corrective actions for improvement, or we may have an initiative to reach a specific management goal.
The Work Road Map
Something I ask all my domain architects to do is a work road map – anything that is going to take more than a week to complete or will tie up one or more resources should appear here.
I ask that the domain architect connects with both Product Manager & Service Manager in order to get a perspective of whats actually going on in terms of work within the specific products and services.
Each block on the “Road map” (its a road map view in BiZZdesign’s Enterprise Studio) is a work package which has start and end dates. The arrows on this diagram are denoting dependency. We need to understand the dependencies between work packages, and in the example above “My Collaboration Program” is composed of several projects
Having all work modelled on the one road-map with the associated views allow us to ensure there is no duplication of work happening in the organisation and helps us understand our full workload – it should be regularly used with product managers to prioritise what happens next. Of course every work package on an architecture model can be navigated so we can understand all the places it exists.
We could add a number of other elements to the roadmap view – including plateau’s which would give us a stable state to connect architecture to – for now we are talking of the minimum basics.
Motivation View My Collaboration Program
Its important to note that this is a concern – not a risk – anyone can have a concern – it can be like a requirement, or we can express worries in the same way. Building a motivational view like this gives me something I can discuss with the different stakeholders; with a bit of practice you can create these in meetings, capturing concerns and assessments from the stakeholders. None of my motivation views have stakeholders expressed in them, because in our case the stakeholders are made apparent by the repository structure. I could include them in the motivation view.
There’s a school of thought that we should hide negative concerns, and I don’t agree with that – if we hide them, we can never fully address them, and also we may live with a wrong idea on something – for example, I could spend my career thinking that architecture workload for products is unclear and improperly scoped, when a conversation with the right person might simply inform me that I was wrong – there could be processes in place that I just haven’t been aware of, and for that reason, were never included in my architecture.
Motivational Views are there to explain why we do things. Above i show a simple motivation view – I have been advocating modelling something similar to above because of simplicity – the basic idea behind the view is to explain the “Why” behind the work packages we have – in an ideal world you can develop a full justification and more complex motivational model but for now – The basic things we want to have answered:
Drivers – in the case above the driver / concern is a customer need. This driver reason behind why everything is happening for the work package. Normally I have one driver that’s motivating the whole view, at the top.
Assessments – These are the observations that are forming the rationale behind the work package. In a typical conversation with our stakeholders they will make many assessments on things that we could capture. and connect to our concern. When discussing with stakeholders they normally frame the problem (Driver) and then come up with a whole bunch of things to motivate that. These are effectively assessments.
Requirements – Requirements are the glue that holds everything together in architecture and we could talk about them at length – For now in this simplified mechanism for drawing concerns we create requirements that would mitigate or provide a positive effect on our observations; for example if the observation is that “The media server crashes frequently”, then a good requirement might be: “Media server solution created & implemented to ensure a 99.999% up time”
Goals – The requirements together meet one or more goals. Its important that the goals address the needs of the driver.
Values – The goals have a positive influence on different values -we could define some standard values at our team level – so we can reuse them. If my boss says “We need to reduce maintenance costs” – we could easily automatically generate a view that shows all the goals that provide this value – and show the work packages with them. When we do that suddenly I can have an informed discussion with my boss – I can say – sure we can do that – but look at the road map – we need to de-prioritize some projects accordingly because of resource constraints – Its a much better discussion to have than answering “yes boss” and then trying to juggle a dozen projects you don’t have time for, get overly stressed and then fail to deliver anything.
I could have added positive or negative influences, I could have made our time restriction a constraint – many things could be done to improve the motivation view, but for the sake of simplicity I normally ask someone to do something basic like above.
Prioritizing The Requirements
Once I have the motivation views in place I normally prioritize the requirements – I am normally using MoSCoW rules (Must have, Should Have, Could Have, Won’t Have). This normally influences package definition – we may decide we address our requirements is several packages – for example, high priority tasks may need to be in a priority project and then you can define secondary projects that can be de-prioritized.
Implementation & Migration View
Once we understand the motivations behind our concerns we can take the requirements from our concerns and realize them within a work package like I have done below for the platform implementation project:
The above view further defines the work package. The key components are:
The Work Package – which everything connects to.
The Roles – That are required with the work package – I find it handy to have the association relationships describe how much time is actually required from each resource.
The Requirements and Goals – these are from the motivational view – they tie the motivations to the work package.
Deliverables – these are things that the work package needs to deliver to be successful.
Other Architecture elements – A work package can realize any number of other architecture elements – for example we may create a work package to realize a specific service.
Business Validation & Other Related Things
I will introduce a couple of basic mechanisms we can use to validate our work packages – none of which should take more than a few hours to create if you have a solidly defined idea of your business case and understand your audience. If you do not understand those things I would say the following practices are even more important. Its very important we do not start work unless we can clearly understand the scope of the work, or the values & benefits it provides.
Below I show a couple of typical requirements or principle that an organization might place upon its businesses; most organizations have some kind of principles we need to be aware of:
Products should be returning a revenue of 1MEUR – This doesn’t mean in a year necessarily – but the plan should be in place for when this will happen.
For every EUR we invest we should have a return of 10EUR – Its a basic profitability rule of thumb.
We should try and get our product costs covered by pre-selling ideas to customers. Having a customer commit to buying a completed product fully justifies its cost.
User stories are a basic form of requirement – they take the form : As <someone> I want to <do something> in order to <achieve some value>.
When you write a series of these with different stakeholders you gain a better understanding of who needs what and why. Take a look at the video:
I have already mentioned TELOS in another blog – its an acronym used for feasibility checking. (Technical, Economic, Legal, Operational, Scheduling) Its another thing I could write a lot more about because it is so useful.
Business Model Canvas
When defining a work package for a service or product we may want to consider creating a business model canvas. A reasonable video introduction is below:
We can create a Business Model Canvas that connects directly into BiZZdesign’s Enterprise Studio – its a type of view that can be created in an Archimate model.
Summing It Up…
The mechanisms described here are not complex and do not take much time to implement. For myself, most work packages can be defined and modeled with associated motivation views inside of an hour – the modeling is not the hard part – the more difficult part is clearly deciding what your goals are, who you need, if your business case is strong, and requirements. modelling these individual elements forces an architect and their stakeholders to clearly think about every element.
We could talk in terms of risk here – if you cannot create a business canvas, for a service I could question the fundamental business case. If you cannot identify stakeholders a risk around the understanding of cost and basic feasibility could be raised. With resources being limited and the need to deliver value being ever greater following the methods I describe above give you a good way to describe work and its implications and give a good foundation that can be used to continually manage a complex workload and ensure that the workload is prioritized in a way that you are getting the correct value at the correct time.
A discussion on the different architecture Languages, Standards and Frameworks I like to use in conjunction with each other when providing large scale IT & managed services..
My goal in these first posts is to introduce some of the basic ideas and concepts that we will build upon in later posts. I would love to present forward some things such as TOGAF ADM, and the ArchiMate full model, but those things are copyrighted so I can’t present them forward for now.
There are 3 industry standard mechanisms I normally use when modelling architecture; and although you may choose to use any other, the mechanisms below give a very good coverage of the different aspects of architecture, so when I talk about the role of architect within our company, I am normally having expectations on the languages I expect an architect to be able to communicate in.
ArchiMate – Is a modelling language that allows us to easily bring together different aspects of architecture (Strategic, Business, Application, Technology, Physical, Implementation & Migration, and Motivational). Its important we understand how the business is motivated, how it is realized, how our services are constructed and how these things connect together with both applications and the physical world below it. If we provide consistent architectures and have discipline most ArchiMate tools can provide invaluable business intelligence – I will blog on this further at a later date. Archimate perfectly complements TOGAF. Read more here.
BPMN – Archimate is good, but when it comes to understanding how a complex set of tasks are performed with multiple stakeholders BPMN shines – what would be done over several views in Archimate can be done as a single page with BPMN – its designed to model processes that look much more like traditional flow diagrams within swim lanes. I normally align these more in-depth BPMN processes with Archimate – For example in ArchiMate I model the process, with the different business events that align to the BPMN model. and normally assign the different roles and actors – but then the actual steps, happen within the BPMN model. Read more here.
UML – Is very good for low level data modelling & class modelling & has been around since the beginning of time. In EA I am tending not to use it too much, because at a high level I can represent data objects & their interactions with Archimate – But UML still has its uses with those who focus more on breaking information down into detail & those with a more application based focus. Read more here.
Project & Architecture Governance
Scaled Agile Framework (SAFe) – I like this framework because its relatively simple to use and implement, and provides us a agile development methodology which supports us in a movement towards Dev-Ops, and the continuous delivery of value. Read more here.
The Open Group Architecture Framework (TOGAF). A lot of people have said to me that they feel this is a heavy framework that is monolithic and too documentation focused. It doesn’t have to be this way; we can adapt things to be fit for purpose. I think the framework nicely captures the things we need to consider in architecture. Read more here.
For me, a good working practice is actually a hybrid of these two mechanisms – because we need to flexible methodology that covers all the key areas but delivers continuous value.
This is the international standard for architecture description – and its one of my favorites. When I first read it I was very excited, because it formally said a lot of things I had been standing on my soapbox about for years. It talks about how to describe architecture and covers core needs such as concerns management, and how these need to map onto an architecture solution that considers its stakeholders. Its under a 100 pages long and a recommended read for anyone who is serious about doing architecture.
Adding Additional Value
This wouldn’t be complete without mentioning IT4IT and ITIL.
IT4IT – Provides a reference architecture for managing the business of IT; at its core is the IT Value Chain, and is very much focused on providing value to the business.. Read more here.
IT Infrastructure Library (ITIL) is a set of practices of IT service management – very well know, and very well supported. It can be used in conjunction with IT4IT. I do not know a good resource for free information on ITIL – there’s a lot of material out there though.
Summing It Up…
There are of course many standards we can apply at are equally as good as what I show above, but these are the ones that i found work well together and I like to have implemented together when i have a choice
ArchiMate is designed with ISO 42010 in mind, it’s by The Open Group, who also do TOGAF and IT4IT, so there’s a fair amount of alignment between these. SAFe and TOGAF require a bit of effort to establish good working practices. and IT4IT quite nicely facilitates ITIL which is very much an industry standard.
In this blog I discuss what an IT architect is, and the common expectations that I normally have on all architects – Regardless of whether they are Business Architects, Infrastructure Architects, Enterprise Architects or otherwise.
There are many definitions of what an architect is if you google the term “architect definition” – but all of them have some common threads between them. The reason we re-use the terms that we have from the physical world is designing information technology systems require the same levels of discipline and structure. In traditional architecture you need to plan before you build because rebuilding is a costly exercise; and this holds true of IT architecture, even though the nature of IT architecture is changing and we now see trends towards more agile thinking. Agile methodologies don’t mean that we forgo the design processes, it means we work with smaller units of work and a slightly different focus – they still need scoping, goals, to provide clear value, a design, and plan for execution.
Today I am discussing the general traits for all architects – Its true that specific architecture roles have specific definitions and needs – Infrastructure architects, for example, need a basic grounding on technical concepts that relate to their roles – We should be careful not to blur the roles of architect with those of technical specialist; a good architect can capture requirements from different stakeholders, and leverage their expertise – technical specialists are stakeholders in the architecture, and architects can leverage that experience. Another important differentiation between the roles is focus – technical specialists are often good at creating technical designs but do not focus on other aspects of architecture – i.e. they capture tools and technology, but do not think of processes & roles, information flows, governance & People.
Some other common things I see in the definition of an architect:
Architects design structures. It doesn’t matter if we are talking about physical structures or information structures – we start with a skeleton or a concept and we build upon it.
Architects oversee the building of structures. In many places its stated that architects build things – which can be easily misunderstood. If you look at an architect on a building site, hes not there laying bricks. although he may take an interest in the work that is happening – he may check the quality and make sure his requirements are met – Its the architect that has specified the type of brick and ultimately where it goes. In the execution phase of a project an architect is there to ensure that everything goes according to plan. The building industry has many regulations that need to be followed, many risks, and methodologies and redesigning part way through a project is expensive – just as it is in the IT world.
Architects design and plan. They need to be able to turn a fluffy vision into something more concrete that meets many sets of requirements – from legal, from the customer, from their own best practices, they need to understand risk and cost, and they need to be able to communicate these things in industry standard ways with different stakeholders. They interact heavily with managers to realize their visions, and need to be able to clearly manage risks and requirements, as well as apply methodology in order to help identify risks in areas we may not think of. For example, in IT, we might teach architects to know about the TELOS acronym when looking at requirements – assessing Technology, Economy, Legal, Operational, Scheduling. If you think through those words when you are assessing an architecture you can easily start to spot things that may be missed otherwise.
We need to train our architects to think, and to practically utilize methodology, and follow standards such as ISO 42010, the standard for architecture description.
To me, Tom Graves said it well – “Things work better when they work together on purpose” – and to my mind fundamentally architects are there to facilitate this.
When I first started working with the Tieto Office 365 internal initiative we hadn’t made too many decisions on how to move forward with implementing a collaboration platform – This blog is about the first thoughts I had back then; which still hold true now.
At the core of any business, and any collaboration system is information – the management and protection of that information one of the keys to its success. Tieto, like pretty much all companies has information policies and its essential that we adhere to them. Some core things to consider:
Information classification – We have a standard set of classifications and those classifications determine how we manage information. Anyone is allowed to see public information – where as confidential information has a controlled access list for example. any information we store has a classification, and that has to be identified in our information model. Typically the classification of information is related to the risk of its exposure to various parties.
Information Ownership – Information is always owned by someone, and that someone is responsible for the classification of information – although there may be some mandatory rules an information owner may need to adhere to. Its also important to know there are differences between an information owner, and information author. although in many cases its often the same person assuming those responsibilities.
Information Traceability – establishing ownership is part of this but we need to be able to effectively track or locate information.
Information life-cycle – its important to understand if information is current or outdated, and to establish rules around things such as information retention.
What this means in real terms is we need to ensure anyone using our systems can classify information and it means we have to put in mechanisms to in some cases enforce policy. Discussions started early on over minimums that our internal security team needs in place – but at its core, before we can do anything we need to ensure our information needs are managed and then add the layers of security on top of that – for example we need to consider things like multi-factor authentication. Requirements are drawn up by our security team in collaboration with the architects, and in some cases we need to consider modernizing. Our versioning policy is a prime example of this. On most modern systems we have a simple major/minor approach to version management – many people are unaware of the formal policy we have at work, because our information systems don’t support a version that is expressed something like 1.0.1-2D.
With any kind of architecture engagement requirements management is important; one of the biggest problems I have had working in my current role is getting focus to be more at a business layer than a technology one.
Security is not exception to this – its very easy for a security policy to be dictated by the functionality of a tool, and we should be very careful not to do that. This is why, with our security team we have tried to lay out the requirements before even talking technology – even so, I sometimes get the feeling that some of the see come directly from a Microsoft manual. Its important that we discuss and balance the requirements – and decide what is and is not in scope. Some things will be mandatory, and some things may not be in scope; that’s OK – it can be managed as a risk – and sometimes the business can decide to accept a risk – because business drives security, not the other way round.
There’s a balance. The users in the modern age expect a certain amount of freedom on how they work with information, but at the same time we need some controls in place to protect the organisation and its members.
Too much freedom – and you have risks related to information getting into the wrong hands, or lost, or worse. Too little freedom and it invites users to find innovative ways to work around the systems you put in place. If I restrict who can access a site for example, then people will work around it – they may start emailing files around and suddenly you lose control of where the latest version of your file is, or who has access to it. If I cannot create my own teams site, then maybe I will want to use something else. In such a case by restricting access we have effectively lost control of access all together.
We have been very mindful of this from the start of the Tieto project – Tieto has many ways of working, and no one way fits all. When we first started on-boarding users into Office 365 some policy decisions were made – people in specific customers were not allowed to be on Office 365. When it comes to collaboration, Not allowing people on creates a very real problem. suddenly those customer teams are alienated from a wider Tieto community, which means we either loose our connection to them, or they find a way of working around the mechanisms we have in place. In Tieto, any restrictive policy we put in place is going to impact someone somewhere.
So how do we address this? We know already the information we must keep to have a minimal level of security, but more important if for us to understand our information policies
Knowing Your Responsibilities
As information owners we all know pretty much what we should and shouldn’t do, and to be successful we need to have a level of trust that our users will know both our information policy and what their industry/Customer does or doesn’t allow. Rather than restrict we need to educate.
For those users in customers that are not allowed to have information online we need to ensure we have a system in place that makes it very easy for the to understand where they are – whether it be on O365, or on our private internal solution. At the top level we decided we would color code. The site theme for Office 365 should be different to on premise so that we can immediately see where we publish.
We need to make sure that as part of this project our communications team makes it fairly clear what our responsibilities are.
How This Is Realized In Technology Terms
We implement core content types that are mandatory and a basic template that all others are derived from – out of the box SharePoint, and we have taken other decisions on things like Multi-factor authentication. We then continued a discussion on how and what we need to implement around EMS and other technologies.
These are the things we were considering at the beginning and still form important parts of the ongoing work because of course outside the office 365 conversation, there is also a device management conversation going on.
I hope this gives a little insight into some of the information considerations we had when practically moving to Office 365 & its surrounding technologies.