DevOps: A breakdown of common misconceptions

DevOps is all about culture.

It is about creating a culture of homogeneous and inclusive work efforts between all team members- from the project manager to the QA subteam- in order to achieve a smoother and faster-flowing software lifecycle.

In today's IT environment, everyone has different notions of what DevOps is and what it entails. At times it can be a source of contention and friction between the implementers. The DevOpsDays conference in Belgium was only nine years ago, in 2009. Yet, for being so young, the approach has garnered more than its fair share of confusion. Let's review some of the distortions.

DevOps Team

Some organizations leap at the mention of DevOps to create an entirely new team, complete with managers and other resources. Based on the definition provided by DevOps Dictionary, this is a problematic approach to DevOps, which focuses on its emphasis on deviating from overspecialization. Using this paradigm, creating a team just for DevOps is paradoxical. 

CI/CD is DevOps

Continuous Integration (CI) was first coined by Grady Booch in his 1991 book "The Booch methodology," in which Booch identified a need for continuous integration of code as part of a healthy software lifecycle. Nowhere did he stipulate that CI would occur more than once daily. 

Continuous Delivery (CD) is aimed at releasing software more frequently while raising its level of reliability through the automation of testing, packaging, and monitoring. Continuous deployment becomes a part of the CD chain when we replace manual deployment process with an automated one.

To say CI/CD is an imperative component of DevOps, would be to say a an engine is part of its tune-up or a tree is part of its pruning. 

It is 5-Stage or 7-Stage?

The confusion between the levels DevOps maturity and stages of DevOps is yet another source of disagreement.

There are 7 stages in DevOps:

While there are 5 levels to DevOps maturity:

To be continued...

Architectural Patterns

After 8 month this is my first post on this blog. I have a lot to blog about by which mean many posting to come. These postings will be mostly about Architectural Patterns and related  subjects.

One might imagine Architectural Patterns(AP) are same as Software Design Patterns(SDP) but with an architectural twist,  while in reality the realm of Architectural Patterns is much broader than that of SDP. Microsoft Corp refer to the AP as Architectural Styles. While one can depict the architecture in conjunction with patterns but  patterns are not just a great definition and solution to parts of the architecture. To better understand this lets talk about the steering mechanism used in cars. That is a pattern so is the fuel delivery system they are concepts with abstract meaning and materialized implementations. When someone talks about the fuel delivery system you don't need to see how they implement it but can visualize the how it might be materialized. Now as many types of vehicles can implement the pattern steering same goes for APs.

Architectural sub-domains

Sub-domains deal with compartments we have in an overall solution architecture. in most cases APs deal with sub-domains. Some APs to sub-domains relations are:

Figure one shows two sub-domains, service and data architecture and the the list APs related to them. The bar at the bottoms shows solution and design patterns which cross these two domains. We will visit each of these APs and related SDPs and Solution Patterns.

Zachman 3.0

Zachman Framework 3.0 is so far the best iteration of this comprehensive architectural framework. I recommend everyone to take a look the site: http://www.zachman.com/.

As for me I like to look at the Zachman Framework from this prospective:

Zachman Farmework

In my opinion Zachman Framework is one of the most comprehensive classification methods for enterprise architecture.  This framework was first designed introduced by John Zachman in 80s while working for IBM.
Using this methodology has helped me in tackling  requirements/design for large scale implementations.
The Core
The base questions which need to be answer in this framework are: Why, What, Where, Who, How and When. These questions have to be answered by different groups: Planner, Owner, Designer, Builder, Programmer and User.

The intersection of these two  sets creates a matrix of design artifacts and documents and application.
I highly recommend  reading more about this framework and using it.

Some Papers
Zachman Poster
The Zachman Framework For Enterprise Architecture
Top Four EA Methodologies

Books:
Enterprise Architecture Using the Zachman Framework (MIS)

Representational state transfer (REST)

Roy Fielding in year 2000 for the first time introduced the term Representational state transfer (REST) to the software world. This is an architectural practice used for distributed hypermedia, while the largest implementation being the World Wide Web.


The Core 
In essence the REST Architecture consists of three parts:

1. Client: This is where all the request get initiated.
2. Server: Where the respond to a request is processed which can be in different forms.
3. Network: This is the means through which the client and server correspond. (Usually not mentions as a part of the Architecture)

Now the other pieces which make up this architecture are : Resources, Representation of the Resource, and State of the resource.
In this architecture state of the client constantly in transformation as it progresses in its requests. The server in response has many states to consider in a given time since it can be responding to many clients at a given time, in essence the sever is stateless.
This architecture is a great bases for a well designed browser based application.
Below you'll find links for several good resources for REST:

Short papers or Presentations:
Roy Thomas Fielding: Architectural Styles and the Design of Network-based Software Architectures
RESTful Web services
Rest of REST
What is REST
SOA with REST
RESTful Web Services for Java
RESTful Java with JAX-RS
RESTfulWeb Services Developer'sGuide

Books:
RESTful Web Service
RESTful Java with JAX-RS
Service Design Patterns: Fundamental Design Solutions for SOAP/WSDL and RESTful Web Services