Author: Trudie

Categories
Blog

Building a Zero Trust Model

New buzzwords in the world of IT come and go at an alarming rate. Just when you think you are getting your architecture or processes up to scratch with some new benchmark that your organisation needs to “comply” with, there is a new benchmark to supersede it. So here is another IT buzzword (or buzz-term if you prefer) to add to your ever growing list of compliance goals: Zero Trust.

What is Zero Trust? Do I need it? How do I get it? How will it help me?

The Zero Trust Network or Zero Trust Architecture model is a concept for IT security that adheres to the belief that an organisation should not automatically trust anything inside and outside its perimeter walls. It goes by the regulation that anything and everything that is trying to gain access to an organisation’s systems must be verified before being granted access.

More conventional type security models work on the architecture that considers everything inside the organisation’s network perimeters can be trusted. These days with more awareness around increased attack sophistication and the rising use of BYOD, more resistance needs to be applied if someone were to gain access inside the corporate firewall to help prevent them from moving through internal systems too freely.

A Zero Trust model essentially works on the principle that all access should be cut off to you until the network knows who you are. The model is designed this way to address lateral threat movement within the network by leveraging micro-segmentation and granular perimeter enforcement, based on user, data and location. Lateral threat movement refers to techniques that hackers use once they are inside the organisation’s network, to move through it looking for assets and data of value. To identify and stop this movement, a trust model will correctly identify who the user is, which application they are trying to reach, and if the action is considered an appropriate session. When trust gets breached or challenged, so does the user with some applied friction.

So how do you work towards building a Zero Trust model? Prepare for the build and implementation process to take time. To begin securing the IT environment the organisation will need to look at reviewing various existing technologies and governance processes. A working model draws on technologies such as Multi-Factor Authentication (MFA), IdAM, RBAC/ABAC, orchestration, analytics, encryption, scoring and file system permissions. It also calls for strict governance policies to be enforced such as giving users absolute minimum access they need to accomplish their assigned task.

Building this kind of architecture can be overwhelming for even the most experienced of security teams and it becomes even more complex in larger organisations of course. It would be a whole lot easier if we could all build it from a blank canvas, but the frustrating fact is that most of us are having to deal with a load of legacy systems first which will undeniably mean that you are going to feel like you are going to have to go backwards before you can go forwards.
Above all, there needs to be a security strategy before anything can be put into practice which not surprisingly is a major piece of the puzzle missing from most organisations. To assist your organisation in developing a strategy that will realise a Zero Trust model more quickly, consider this five step strategy roadmap to follow:

1. Identify your toxic data sources:
Identify and classify the data that you need to protect (you can’t protect what you can’t see!)
2. Map the transaction flows of that toxic data:
Understand how data flows across the extended network and between resources and people (employees, partners, customers)
3. Architect your Zero Trust micro-perimeters:
Design the micro-perimeters to be placed around toxic data and segment them with physical or virtual appliances
4. Use Security Analytics to monitor your Zero Trust ecosystem:
Continuously log and inspect all traffic, update rules based on the visibility and intelligence gained from the security analytics
5. Embrace security automation and orchestration:
Create an automated rule base to take immediate action based on confidence levels and business impact

These are the stepping stones that strategy and automation experts such as Diaxion can help organisations flesh out and develop to get closer to achieving a Zero Trust network architecture. With these steps being embraced, your Zero Trust strategy can be the blueprint for your security architecture, addressing and handling the basic to complex vulnerabilities that cyber adversaries target in their attacks. Engage us to work with you in building the foundational needs in architectural security of your data, workforce and workloads that will achieve a Zero Trust ecosystem.

Categories
Blog

Modernising the Data Centre


Continuing our focus of working with our clients on defining and assisting on their DC Modernisation journey we have over the last six months expanded our partner community to include:

Hashicorp – for secrets management (Vault), Provisioning (Terraform) and Orchestration (Nomad)
Unlocking the Cloud Operating Model White Paper
Cloud Checkr – for cloud compliance checking, best practice compliance, monitoring, cost optimistion and management
Device 42– CMDB and application dependency mapping, specialising with Jira service desk support
Google Cloud – GCP / GKE, for true multi cloud and container enablement
Github – enabling the evolution on a modern CI/CD pipeline on premise as well as in the cloud

These are in addition to our existing partners:
Docker
Puppet
AWS
VMware
Microsoft
EMC
CISCO
Apptio

Our new partnerships were identified and established to fill capabilities within our clients hybrid cloud, multi-cloud and general DC modernisation efforts. With the enablement of Google, Diaxion now has multi-cloud capability across Azure, AWS and GCP and protected clouds such as Azure AU Central and AU Cloud.

By focusing on people, process and technology to represent value to the business in all aspects of our engagements, we are able to unlock the fastest path to value of the cloud and your DC modernisation journey.

For more information on how this eco system can help you please reach out to us to leverage our experience and knowledge.

Categories
Blog

When not to use Agile

The article will provide a (very) short overview of Agile software development and Agile project management. It will then look at where an Agile approach to project management makes little or no sense and, some of the possible issues.

Agile takes an iterative approach to implementation. It requires collaboration between cross-functional teams. These do not start with a fully complete or final project plan, but adapt their planning to the environment and circumstances with the aim to achieve evolutionary development and close alignment with changing business needs. Continual improvement and rapid reaction to change are two features of an Agile process. Generally Agile looks at a small number of requirements only.

Software development is a good fit, in most cases, for an Agile approach, where the Agile method allows to quickly adapt to fluid requirements and changes and to only develop what is useful. For project management the combination of Agile with Scrum has the potential to increase the quality of the deliverables, cope better with change and being able to stay better in control of the project schedule and state, even when there are changes.

A variety of projects can benefit from an Agile approach, e.g.

  • Software development or implementation
  • Service and Operational Model definition and implementation
  • Target State definition and implementation

    • However, while the “waterfall” method may be seen as old-fashioned and unfashionable, there is considerable value in choosing this approach in projects. The waterfall model breaks downs activities into linear sequential phases, where each phase depends on the deliverables of the previous phase.

    The waterfall method is suited for all projects – or sub-projects – where there is a clearly defined goal and outcome.

    Examples include

  • Requests for Proposal/Quotes;
  • Transition of outsourced environments; and
  • Vendor and Contract negotiation (to a large degree)

    • These types of engagement have – in most cases – a clearly defined outcome and path to the outcome.

    Another risk with a – supposedly – Agile project management approach is to end up with an unworkable and unsuccessful hybrid of both approaches (Agifail or Scrumfall, Water-Scrum-fall is slightly different). This can include:
    1. Excessive rules for the daily (Agile) stand-up meeting:
    An initial kick-off meeting for the stand-up resulted in excess of 20 rules that people were meant to comply with
    2. Jargon without meaning
    User stories can be a valuable tool as can be other components of Agile project management but, they must be used in a meaningful way and must be understood by all of the project team
    3. Not working as a team
    Where several groups have to work together to achieve an outcome, they should:

      i. Work together as one team: it does not make sense to have several different project meetings for the same project that people should be working on jointly. This especially should include third parties, if they are part of the project.
      ii. Use the same approach: be consistent with Agile or Waterfall for the entire project team. Things will clash, if one group has a 3-month Gantt chart with hundreds of items, while another has a multitude of user stories.

    4. Emphasis on the approach and not the outcome:
    It does not bode well, if a fraction of the required people attend the daily stand-up meeting, tasks or user stories are rarely completed and there is an insistence on the rules (“we cannot sit down – this is a stand-up meeting”, “we have run out of time – this meeting must not exceed 15 minutes”). This point carries the highest risk, as it can endanger the whole project. To provide an example:

    Realising at some point during vendor negotiation that amongst the 30 user stories that have been worked on, the Legal team has never been involved to review the contractual documents and the contract has to be signed at the end of the week.

    Both approaches – Agile and Waterfall have their unique strengths and weaknesses. Care should be taken, when choosing the approach for a particular project. Some flexibility can be quite beneficial with a Waterfall approach, i.e. the initial project plan should not be taken as unchangeable; likewise some rigid structure can be required with Agile. Diaxion has used both approaches with good results.

    Categories
    Blog

    30 second guide to building an Operating Model

    In my previous article I discussed what an operating model was and what value it brings. I also said that I would go through approaches to building your operating model. First lets go back and state what an operating model is:
    • An operating model describes how the business is run. It describes how the business deliver value and enacts its strategy.
    So, in this article we will be looking at approaches to build your target operating model and how that might translate into implementation. We cannot look at all options but I will give you some of my views and a couple of tools that you can use. How to build your operating model The key pre-requisite of building or changing your operating model is to have a strategy that is clear and agreed. If you don’t have a clear strategy or the strategy is trivial (in the nicest sense of the word) then you have one of two problems: 1.Your area of responsibility is too small to have its own strategy. This is easier to deal with and requires you to be contributing to the operating model that exists at a higher level both from a delivery point of view and get involved in changing or building the operating model. So for example if you look after the development of a particular application or you manage storage for a typical organisation then you probably don’t need an operating model, but will be working within the operating model of the application delivery or infrastructure and operations area. 2.The second problem is more serious but also solvable. You need to have a decent strategy – if you don’t have this then you cannot create an operating model as the operational expression of the strategy is the operating model. While you can create your own strategy, it is often useful to get an outside perspective on your organisation and employing the use of consultants to help, should not be ignored. This does not mean you have to bring in McKinsey or BCG; there are many organisation that can help (rather than take over) at a more reasonable price, such as ourselves. So after much gnashing and grinding of teeth, long discussions, reasoned(?) arguments, you finally have a strategy that the significant majority agree on – not everyone will, but that is just life! What next? For one thing it is not easy, don’t expect the model to be complete in a week or even a month as a new or changed operating model will change:
    • Processes
    • Organisational structure
    • Roles
    • Some technology
    Your organisation should focus on the processes and people first. Bear in mind that operating models across similar organisations have common components but not two will be exactly the same. Here is my 30 second guide to building your operating model:
    • Define your operating model design principles
    • Define your operating model operating principles
    • Understand and document the value chain(s)
    • Understand and define the capabilities required to deliver the value chains including supporting capabilities
    • Understand and define the processes that make up the capabilities
    • Organisation and roles and skills of the people
    • Organise the resources and location to support the people doing the work
    • Identify the information and systems to support the capabilities and processes
    • Define the management systems supporting the planning and performance tracking of the work
    I am describing a couple of the parts of the above so they are clear in what I mean. Some actions are part of normal project management or ongoing management of the organisation. Design principles and operating principles provide the foundation guidance for the implementation and then the on-going run. The principles have different focus: design principles focus on the non-negotiables of what is trying to be achieved; operating principles focus on the execution of the operating model once it has been designed as well as governance. The value chain describes the high level value adding activities that deliver the product or service supported by the operating model. The capabilities are the combination of people, process and technology that deliver outcomes to support the value chain. What tools are available to help me build my operating model and what about approaches? What is available to help me build my operating model apart from the information above? Well there is quite a bit, searching Google will give you quite a bit of information but I thought that I would cut short some of that and provide a good base from which to work from. The first and most important is the value chain or value chains (for a large operating model). These are also known as value chain maps. These represent the logical steps to deliver value in supplying the end service or product. There is the classic Porter value chain model but this is probably less useful here but his later work does have some areas worth reading. Some examples follow: Payments Generalised manufacturing Enterprise Financials I really like the operating model canvas by Andrew Campbell, Michael Gutierrez and Mark Lancelott. They have an excellent website at https://operatingmodelcanvas.com/. The following is the basic template: There is an associated website ashridgeonoperatingmodels.com which has lots of useful information. Another good resource is the book Enterprise Architecture as Strategy by David Robertson, Jeanne Ross and Peter Weill, out of MIT Sloan, which despite its name is about execution rather than strategy. Defining the design and operating principles will be a key governance and guidance task. It will be complicated by the need to gain agreement from quite a few stakeholders. This leads on to understanding that defining or changing your operating model is as much about communication and buy-in as anything else, as the people change can be significant. The organisational model is likely to be fairly specific to your organisation however skills profiles for various job families are available for areas such as IT, HR, Finance etc. Business architecture courses can be a good way to get in to the understanding of how to start building value chains and operating model, but does not provide the whole story by any means. There are not that many business architecture courses; Enterprise Architects run one as well as a number of other companies. A number of the large consulting organisations, e.g. McKinsey, Strategy& (ex Booz), Boston Consulting (BCG), etc., have good articles on operating models but less on the actual implementation. This is probably because they want to do this for you! But you can glean good direction. My caution is that they can be very high level and not entirely practical – good for the board but not so good for the execution team. Are there any operating models bases I can just use? You may be wondering if there is a way you can shortcut some of this work by using pre-existing models and there is, but you have to be sure that the model you are taking on does not impact your competitive advantage. Generally within IT this is not an issue unless you are selling IT products or services directly. Below is a list of models that you could use, some of which you may well be already familiar with.
    • ITIL – the well-known service framework model about identifying, running and maintaining services. To my mind it is less on the build and more about the run, but the concepts have applicability outside of IT
    • COBIT – Control Objectives for Information and Related Technology
    • eTOM – Telco based operating model that can be adapted for IT
    • IT4IT – OpenGroup IT operating model
    • BIAN – Banking Industry Architecture Network
    • IAA – Insurance Application Architecture (IBM)
    • IFW – Information Framework (banking framework from IBM) – this has been adapted to a number of industries and has IT specific sections
    Of these IT4IT is probably one of the most interesting as it starts moving away from the traditional “Plan, Build, Run” model that many organisations try to use. The model has four distinct values streams (chains) of which ITIL generally corresponds to the last two along with some of the supporting activities Conclusion I have provided a view of the steps needed to create a basic operating model, some tools and techniques to help you along the way and finally a couple of shortcuts (pre-done operating models) to give you an idea of what they should come out like or, to adapt for you own needs. Your operating model will not be exactly the same as someone else’s as, while there will be some commonality (especially in IT), the combination of organisational culture, organisational maturity, size and the focus of outcomes will alter each end result. My final word is: don’t try this yourselves if you have not had any experience. It takes existing knowledge and a consulting mindset to make this successful. This is often not a skill that IT teams have, especially in smaller organisations that do not have dedicated strategy and enterprise architecture staff. It is also not a typical project management role; your standard project manager will flounder, direct focus to the wrong areas or need too much detail. So again get some professional help if you are looking at this for the first time.
    Categories
    Blog

    Redundancy in the Cloud

    Traditionally, large corporations have either maintained their own data centres, or rented rack space in a data centre managed by another company. Redundancy, in this context, has to be maintained on several levels:

    Power

  • Two or more independent supplies, each capable of maintaining the load in the event of supply failure
  • Uninterruptible power supplies capable of carrying the load until power is restored or backup generators are brought online

    • Cooling

  • Two or more Heating, Ventilation and Air Conditioning (HVAC) systems, with enough spare capacity to cover the data centre’s requirements should one system fail

    • System hardware

  • Multiple internal power supply units
  • Multiple independent network connections
  • Multiple independent storage connections

    • Application

  • Multiple systems, each capable of maintaining access to the relevant application subsystem in the event of a single failure elsewhere.

    • Geographical

  • Spreading the redundancy across multiple sites, such that if the main site goes down, another site can be brought online quickly.

    • The advent of cloud service providers changes the equation significantly. The provisioning of power, cooling, and system hardware redundancy to meet contracted service level agreements is now the sole responsibility of the cloud service provider. As a result, companies leveraging the cloud need to architect redundancy through networking and geographical measures.

    When designing an application for deployment in the cloud, the key determining factors in deciding just how much redundancy to build in are two that often stand in opposition.
    1. The criticality of the application to the business
    2. The cost of increased redundancy.

    For an application that is business critical, the cost of a high degree of redundancy is compensated by the cost to the business if the application becomes unavailable for an extended period. For a low priority application, a reduced level of redundancy is reasonable.

    The exact details of how the redundancy might be provided can vary from application to application. Having spare instances that can be brought up when necessary might suffice for some. Maintaining redundant instances, running in parallel across multiple sites (AWS and Azure availability zones, for example) might be reasonable. And in some cases, redundancy across a large geographical distance (Azure and AWS regions) will be the way to go. Having redundancy provided by the cloud provider means that your business can focus on the important matter – ensuring availability of your applications in accordance with your business needs, rather than the infrastructure and plumbing necessary to make it happen.

    Alternatively, if the application in question is not an in-house developed application, it may be possible to purchase the application via a service subscription. In this scenario, the business pays the service provider to run and maintain the application. Responsibility for redundancy rests entirely with the service provider; as long as they hold up their end of the bargain, the business only needs to pay the bills and maintain a reliable Internet connection. This does, however, bring its own set of downsides: upgrades and maintenance are done on the service provider’s schedule, rather than the business’s, with the consequence that outages can occur at times that are inconvenient. For common applications, the savings in not having to maintain the application internally may well be worth these inconveniences, especially if the service provider commits to providing adequate advance warning of maintenance outages, and/or scheduling those outages for weekends or other periods of low demand. As always, the analysis of which approach will work best needs to be done on a case-by-case basis; there is no “one size fits all” solution to these problems.

    Categories
    Blog

    Device42 – a flexible CMDB

    Maintaining accurate information about the entire IT infrastructure has proven to be surprisingly difficult. The IT Infrastructure Library (ITIL) uses a Configuration Management Database (CMDB) as an integral part for IT infrastructure operations and support. A CMDB is meant to contain accurate, relevant and up-to-date information about hardware and software components and their relationships to each other within an organisation. Ultimately this provides among other things the information to reduce risks to the environment by e.g. knowing the impact of changes to the environment.

    Configuration Management is the process to maintain all Configuration Items (CIs) and includes the tasks of:

  • Discovery – which items to include and ensuring new items are added to the CMDB
  • Security – Limit access to the CMDB and restrict changes to CIs to authorised staff
  • Auditing and Reporting – ensure the CMDB is accurate; this also includes the removal of decommissioned items

    • We have discussed in a previous newsletter the challenges in maintaining a CMDB within an agile or DevOps environment, which increases the complexity of managing a CMDB. Diaxion’s experience is that the maturity of CMDB implementations varies significantly between our clients. The two biggest challenges have historically been

  • the initial setup of the CMDB using data from various sources – ranging from spreadsheets to automated data imports via APIs
  • maintaining and updating the CMDB

    • Both tasks can require significant resources from the IT team, which should be able to focus more on improvements and new services instead. A successful CMDB implementation will ensure that most of the CI discovery, maintenance and removals – i.e. Configuration Management tasks – are automated and require little or no oversight.

    Diaxion was asked by one of our clients to investigate CMDB options within their specific IT Service Management environment. The selected product – Device42 (https://www.device42.com) – was able to satisfy the critical requirements, is easy to install and easy to configure with many tasks that can be automated – providing a capable CMDB that integrates easily into most off-the-shelf IT Service Management tools.

    Device42’s features include:

  • Agent-less discovery for most environments with agent(s) available, if required
  • High level of automation (e.g. discovery and removal)
  • Integration with other tools, API
  • Support for most environments including Cloud, Container environments

    • Device42 – like any CMDB – supports other IT Service Management processes like Change, Incident and Problem Management, facilitates reporting on the life cycle status of IT infrastructure. Device42 is offered as a standalone CMDB, which allows to move to a different ITSM solution whilst keeping the CMDB content.

    Diaxion decided to partner with Device42 and can provide DevOps consulting and implementation services.

    Categories
    Blog

    Container Services on Microsoft Azure

    Containers are one of the most topical areas in cloud computing. In the last couple of years, container based services have become increasingly popular for both on-premise and public cloud. This blog will explore the container services provided by Microsoft Azure and cover the basic concepts of Microsoft Azure Kuberetes Service (AKS), Azure Container Registry (ACR) and Azure Container Instance (ACI).

    Azure Kubernetes Service (AKS)

    Microsoft’s Azure Kubernetes Service, known as AKS, provides a simple deployment, management and operations interface for fast access to container based services.

    Features and Benefits

  • Automatic updates and fixes
  • High availability and reliability
  • Self-healing ability
  • API monitoring mechanism
  • Access control through Azure AD
  • Role Base Access Control (RBAC) control for Kubernetes clusters
  • The Control plane/Master nodes is free to use
  • Easy managed by AZURE CLI or AZURE Portal

    • One key point about the AKS service is that the platform is managed by Microsoft. There is no requirement for the end user to configure a master node or other base infrastructure. Users use the API endpoint to manage AKS using the Azure Cli -az.
    By integrating AKS with Azure Services Azure DevSpaces , Helm , Azure DevOps Project , ACR , ACI, Azure Monitor , a complete DevOps solution can be provided for cradle to grave (development to the production).

    Azure Container Registry (ACR)

    Azure Container Registry (ACR) is a service that stores and manages container images for Azure deployments in a central registry. It manages and builds the Container Registry using Docker Registry-compatible commands and utilises private docker container images.

    Features and Benefits

  • Allows storing images for all types of container deployments
  • Efficiently manage a single registry replicated across multiple
    regions
  • Reduce network latency and eliminate ingress/egress charges
  • Compatible with the open-source Docker Registry v2
  • Keep images safe by authenticating and managing access

    • Azure Container Instance (ACI)

    Azure Container Instance (ACI) is a service that lets consumers deploy and run containers without managing servers. Container instances can be deployed in no time and provided with a public IP and full domain name (FQDN), which can be directly accessed from the Internet.

    As shown in the figure below, ACR provides container storage and can manage images via ACI.

    Reference:

    • https://social.technet.microsoft.com/wiki/contents/articles/51499.azure-kubernetes-service-aks-getting-started.aspx
    • https://docs.microsoft.com/en-us/azure/dev-spaces/
    • https://docs.microsoft.com/en-us/azure/aks/kubernetes-helm
    • https://docs.microsoft.com/en-us/azure/devops-project/
    • https://azure.microsoft.com/en-us/services/container-registry/
    • https://azure.microsoft.com/en-us/services/container-instances/
    • https://azure.microsoft.com/en-us/blog/monitoring-azure-kubernetes-service-aks-with-azure-monitor-container-health-preview/
    • https://docs.docker.com/registry/
    • https://docs.docker.com/swarm/
    • https://azure.microsoft.com/en-us/services/devops/
    • https://stackify.com/azure-container-instances/

    Categories
    Blog

    Infrastructure as Code and Documentation

    As the shift of IT infrastructure from private kit in physical racks to Public Clouds and “everything as a service” accelerates, many businesses are finding out that their Cloud projects are getting stuck when dealing with the documentation.

    Some common signs you might have this problem:

  • The documentation took longer to complete than it did to build the Cloud tenancy.
  • Our Cloud tenancy has been in production for a month and the documentation we have for it is already out of date.
  • Our tenancy documentation is just comments in code and we can’t tell at a glance what is what.
  • I can’t get my Cloud tenancy into production because no one knows how to document it.
  • The users design, deploy and then destroy infrastructure in the Cloud before operations even know it exists let alone get to update the design.

    • If any of these sounds familiar to you then it’s probably a sign that the approach to documentation needs to change.

    In the old days of IT, last decade, the infrastructure that was purchased was vastly expensive, very precious and changed very rarely. Infrastructure projects ran for months if not years. The procurement costs were high, and the impact of design errors were large. A few weeks to produce, draft, and approve a high level design (HLD), a low level design (LLD) and ultimately output an as-built was not a serious risk to the schedule.

    None of the conditions that make this approach to design sensible, exist anymore.

    Today, infrastructure services are vastly cheaper and commoditised. This makes infrastructure quick, cheap and easy to change. Infrastructure change is common. Not only has the cost of infrastructure become cheaper but the procurement times have gone from months to minutes. The same fundamental shift in the way infrastructure is documented also needs to happen.

    Cloud Infrastructure is just a small part of what Cloud has to offer organisations and is a small part of business’ IT spending in the future according to Gartner. The majority of the upcoming business spend on IT is going to be in the “something as a service” category. When the operations team is taking care of a SaaS product, a HLD, LLD and as-built for a SaaS product makes no sense.

    Obviously the current approach to documentation needs to change, both in what is produced and captured but also in how the documentation is maintained. The good news is, is that a different approach does exist and it is easy to adopt. The Service Knowledge Base.

    Mature operations teams likely already have some form of knowledge base for turning tacit operation knowledge into explicit knowledge. The Service Knowledge Base extends the traditional knowledge base to also contain facts and information about Business Services that IT provide and manage. This approach also ties in nicely with the shift that IT teams are going through from being solely a provider of IT services to also being a broker of IT services.

    The Service Knowledge Base provides a framework for the capture and description of information related to a business service. It is important to define and agree on what is considered a business service. A useful starting point is to start at a high level and name few standard core IT services that the business users consume. For example:

  • Productivity (Email, Calendar, Voice, Telepresence etc.)
  • Customer Relationship Management (CRM)
  • Financials
  • Service Management

    • If your organisation has a service catalogue or application catalogue it can provide a good source of information on what core services the business uses.

    Services are provided by one or more products or solutions. To test if your list is usable, review each item and see if you have used any vendor names or product names. If you have then you haven’t identified a service, you’ve listed a product. Services have a generic name that should be closely tied to the description of the value the service provides to the organisation. Sometimes services are made up of other small services which together provide the business service. Start with a small simple service that you can easily work with. The next step is to define what critical information about a service should be captured in the knowledge base.

    When defining what information about a service should be captured and described in the knowledge base, there are a few dimensions to consider about the service, this includes:

  • How the service is provided. Is it an “as a Service” service? Is it an app that’s installed in a private data centre on dedicated infrastructure?
  • Who in the organisation is the business owner of the service, i.e. who pays the bills for the service?
  • Who is the nominated technical SME for the service?
  • What are the regular housekeeping and service management chores that must be done to maintain the service in good working order?
  • How do operators gain access to the service to operate it etc?
  • What other services does the service rely on and what other services rely on this service?
  • What interfaces does the service have to other services and systems? Are those systems on the internet, are they internal?

    • These are just a few small examples of the attributes and metadata that can be captured to describe a service. It is important to realise that by completing the knowledge base for a service you have gone from describing a high number of specific configuration values to describing the critical and meaningful information about the service that helps your people operate and provide the service to the business. There are many more attributes that are relevant to all services and there are attributes that may only apply to one or two services. The eighty-twenty rule comes into effect here, you may not get all the information for all the services however if you identify and focus on the core attributes to begin with and iterate quickly over each service you can quickly build up a lot of critical knowledge about each service.

    Finally, it is important to consider how to maintain the metadata and knowledge for each service. Approaches to this need will vary depending on several factors such as sizing of the operations team, how teams get work done and how teams are encouraged to develop good habits and practices. Often new knowledge base systems are built, everyone puts information in and then it’s never used or maintained. Continuous improvement plays a role here however a more fundamental and baked in approach to documentation needs to exist.

    Teams and people generally neglect documentation updates for a few reasons:

  • The documents for that service haven’t been updated for years, they are totally out of date and no longer relevant to the current state of the service. It’s a waste of time to update it.
  • People and teams don’t feel that documentation is important to what they do.
  • Documents are hard to locate, scattered or troublesome to edit.
  • Documentation updates is just forgotten about.

    • Dealing with stale documentation is always a challenge. A key way to address this and resistance to documentation creation and maintenance is to make it quick and easy to create and edit documentation. In general, some form of web based Wiki is the best approach and should also have a “create page from template” capability so staff can quickly create a page for a service. Closely couple the ITSM tooling to the knowledge base. When staff are handling CR/SR and IM tickets they should be able to click a link to access that services Wiki page and quick edit the page from there.

    It is easier to maintain system knowledge and documentation when documentation updates are a baked in stage of the ticket lifecycle. Change the lifecycle from:

    TODO -> IN PROGRESS -> DONE

    to be

    TODO -> IN PROGRESS -> DOCUMENTATION -> DONE

    A change should not be marked as completed until the service knowledge base is updated to reflect what changed. Review the status of the previously completed changes and have the team or person who implemented the change(s) demonstrate what documentation was updated at the following CAB. Celebrate the successful change in the CAB and let everyone see that “It has been XX days of successful change implementation”.

    Service Requests and Incident Management are no different to the approach to change management. Include a step in the SR and IM processes to ensure that documentation updates are completed, peer reviewed and celebrated.

    The goal is to achieve the “its a core part of our approach to how are services are managed” culture in the teams and that good documentation is a valuable part of what the team produces.

    Get in touch with Diaxion today and find out how much easier life could be. With offices in Melbourne and Sydney we’ve helped thousands of people simplify their business with our IT infrastructure services. Become one of them.

    Categories
    Blog

    How do you do backup?

    Since the very earliest days of computing, a major concern for systems managers has been the question of disaster recovery. Making copies of data, and getting those copies offsite, is one of the two biggest problems in ensuring that disaster recovery is possible. (The second is, of course, making sure that those copies are actually usable at recovery time.) Historically, this has been done by shipping tapes offsite. Over the past ten to twenty years, backing up across geographically disparate data centres became a realistic option. And now, the major cloud providers – Amazon, Azure, and Google – have offerings that allow for backup to “the cloud”.

    So, what are the choices? Can you continue to use your existing software, or do you need to use the cloud providers’ offerings? Does the data have to go entirely into the cloud, or can you keep a local offering?

    The answer, of course, is “it depends”. Most major commercial backup products, including Spectrum Protect, CommVault, Avamar, Data Domain, Networker, NetVault, and NetBackup, have cloud storage providers as options in one form or another that can be used to store backup data. Which cloud provider varies from product to product; for example, Avamar only supports Azure; NetBackup supports Azure, AWS, Google, and Oracle (amongst others); and NetVault supports AWS and Azure. These offerings provide a relatively simple way to extend an existing backup system into the cloud, and thereby get offsite copies done quickly. For those with existing investments in onsite backup systems with onsite servers, this may be the easiest approach.

    Alternatively, the three major cloud providers (Azure, AWS, and Google) provide backup as a service for onsite and in-cloud systems, either by in house solutions (Azure), or through third parties (AWS, Google).

    The major reason for moving backups into the cloud is that it inherently means your backups are offsite as soon as they complete. This is a huge win for disaster recovery planning, as there is no longer any significant window of time whilst backup tapes sit on a shelf, waiting for a courier to pick them up and take them to an offsite repository, leaving the company potentially exposed to a site loss event. Furthermore, most cloud providers will automatically provide a level of redundancy for data stored on their services, giving the effective benefits of multiple backup copies with no additional effort.

    Against this is the cost of the cloud service. Pricing models need to be carefully compared and may not necessarily be directly comparable. For example, Azure charges per gigabyte per month, with no cost for retrieval, whilst AWS has lower per gigabyte charges, but incurs a cost if data needs to be retrieved.

    A further potential con to backing up to the cloud may be regulatory requirements. This is only likely to be a concern if data is being moved outside the country of origin, but careful planning to ensure compliance with all relevant legislation is essential.

    It may be worthwhile to investigate these options to compare the total cost of ownership for a fully cloud-based backup service, versus owning and maintaining large disk arrays or tape libraries. Especially for small and medium businesses, the lower amount of maintenance required for a cloud-based solution may be a compelling argument in favour of making the move.

    Categories
    Blog

    Azure Management Groups

    Azure Administrators and IT Finance teams know the feeling of subscription sprawl all too well. Without a well thought and governed plan, customers with a Microsoft Enterprise Agreement (EA) endure subscription after subscription after subscription with minimal management and confused billing.

    Management Groups is a new Azure based service that can be used to resolve those issues. A Management Group can be configured with permissions and policies that can be applied to govern a like set of subscriptions, similar to how Resource Groups are designed to govern Resources with a particular lifecycle.

    Enterprise customers would normally deploy Azure subscriptions following one of three models – Functional, Business Division or Geographic. These three models generally describe splitting the Azure tenancy into multiple subscriptions for use at a Project, an Application or a Business division level. With this level of subscription deployment, assigning policies and permissions is a task that would have to be repeated continuously introducing potential for human error and creating unnecessary layers of management.

    Azure Management Groups remove this requirement as you can setup one or more Management Groups which have the required RBAC permissions and Policies already configured. For each new existing or additional subscription, you simply associate that subscription to the correct Management Group. Management Groups can also be nested where the policies that apply to a higher level are also applied to child Management Groups. The subscription then inherits and applies all the permissions and policies set above it removing the need to perform each task manually. This is an example diagram of how a Management Group structure could look.

    So what sort of RBAC permissions and policies are available for a Management Group? Numerous, and what’s more is the ability to create custom initiatives and policies that suit your business requirements.

    The Policies that can be applied to a Management Group range from the control of an IaaS virtual machine and its extensions, to available geographic locations, the amount of owners assigned to a subscription, storage encryption levels on both disks and storage accounts and a multitude of others. If an existing policy doesn’t fit the specific business requirements, custom initiatives can also be created that are based off policy definitions.

    An example of a custom initiative would be the enforcement of a set of tags that apply to the resources deployed in a subscription. For example, if you had a Marketing Management Group that had Azure resources deployed, you could assign a set of tags with default values and all resources in the subscriptions in the Marketing Management Group had that tag with the default value automatically applied. Another common requirement for a business utilising Azure public cloud is data sovereignty and which geographic locations are used by Azure services. A policy applied to the Tenant Root Group (the default top level Management Group) that the only locations to be used were regions Australia East and Australia Southeast would filter down to all subscriptions associated with that Azure tenancy thereby governing the entire Azure environment.

    Azure Management Groups are a useful and efficient new service that is now in General Availability for Azure that can assist with governing your environment. If you would like assistance in configuring Management Groups to suit your business requirements or even if you would like to revisit your initial Azure deployment model to ensure it meets best business practices, Diaxion is able to assist.