Architecture Is...

There is always a balance between "just do it" and "analysis paralysis." Reference architectures, frameworks and strategic designs run the risk of being too academic and too constraining for the "get it done" mindset. However, in its absence you run the greater risk of thinking success is defined by completing projects and being busy. Efficient and effective are two different things, and you need to plan to be effective.


Projects should deliver to an overall mission or goal, and reference architectures are a great way to provide guiding principles and structure to align project initiatives with the big picture. The DevOps mission is about IT Delivery and building an effective conveyor belt of throughput to support the broader business mission and goals.


There are two general ways to approach architecture and problem solving. One is through point solutions and the other is through platform solutions. Point solutions solve a problem for a specific use case and scenario at a specific point in time. Platform solutions represent building solutions in a manner that are reusable for many use cases and scenarios over time; frameworks that are usable now and in the future.


The following reference architectures were created with a "platform solution" mindset and are designed to support DevOps concepts for the repeatability and automation of IT process flow:

ad


Automation Framework 2.0...

The Automation Framework represents the big picture, end goal vision from a tactical automation perspective. It is Steven Covey’s second habit “Begin with the End in Mind," and provides the "guiding light" for early DevOps discussions, decisions and initiatives. There is a lot to this architecture and it represents a great amount of underlying detail that can not be illustrated in a single diagram. We recommend spending some time to review each blue-box automation domain and its relationship to other boxes. Skydingo’s use of "IT Delivery" is encompassed in the workflow, tools and relationships illustrated here.

Automation framework
ad


Inventory Framework 3.0...

The Inventory Framework provides a schema or structure for all application and system data that makes up a Service Catalog. It should be the basis for ticketing systems with incident, problem and change management, as well as framework for monitoring alerts, event correlation, operational dashboards and financial reporting. For DevOps or Continuous Delivery, it is the common structure for all the meta data that links automation between code artifacts, environments, hostnames, server farms and business applications.

APM

Below is the Inventory Framework with more context. Every organization is unique and will have variations of this framework, but the following is a discussion starting point. Again the structured provides the meta-data framework for dashboard reporting, system availability and financial reporting.

APM
ad


Environment Framework...

Environment frameworks should be strategic and defined by the constraints and functions around user expectations, testing needs, access control, security, funding, etc.

Environments
ad


Organization Structure...

Organization changes are not necessary for a successful DevOps strategy, but structure does have an impact on outputs as described in Conway's law: "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."

Conway's Law should have an influence on big picture organization structure as well as how your product, platform and scrum teams are structured. From the 10,000 foot level, the cloud providers have forged the new IT service model path with SaaS, PaaS and IaaS. These services and the relationships between them represent a good structure to start discussing how your DevOps and IT organization should be built.

That is not to say your organization should consist of just 3 departments (SaaS, PaaS, IaaS), but you should be able to identify accountability for those delivering the IaaS function. Platforms and Applications are layers of accountability decoupled from the IaaS delivery. This may not make sense for a small company, but for large enterprises it allows the IaaS function to compete as a public cloud provider but with private cloud personalized features for unique strategic value.

ad




Copyright © 2011-2017 Skydingo Technology, skydingo.com. All Rights Reserved.