Welcome to the Professor

Please join in the conversation. The Professor is always happy to respond to your questions and hear your ideas!
Email itsmprofessor@itsmacademy.com.

Tuesday, April 25, 2017

Pace-Layered Application Strategy

Historically, many companies have had a single strategy for selecting, deploying and managing applications. They have had a defined structure for classifying applications by value or functionality, but failed to recognize that applications are fundamentally different based on how and when they are engaged by individuals and the organization as a whole and the pace at which these tools need to be changed and updated.  Many organizations are finding themselves with an enterprise application strategy that fails to satisfy the needs of the business community, which has often led to underutilized applications throughout their portfolio.

Gartner’s Pace Layered Application Strategy is a methodology for categorizing applications based on how they are used and how fast they change.   This strategy helps IT organizations rationalize the use of DevOps practices that ensure a faster response and a better ROI, without sacrificing integration, integrity or governance requirements. The strategy has defined three application categories, or "layers," to distinguish application types and help organizations develop more appropriate strategies for each:
  • Systems of Record — Established packaged applications or legacy homegrown systems that support core transaction processing and manage the organization's critical master data. The rate of change is low, because the processes are well-established and common to most organizations, and often are subject to regulatory requirements.
  • Systems of Differentiation — Applications that enable unique company processes or industry-specific capabilities. They have a medium life cycle (one to three years), but need to be reconfigured frequently to accommodate changing business practices or customer requirements.
  • Systems of Innovation — New applications that are built on an ad hoc basis to address new business requirements or opportunities. These are typically short life cycle projects (zero to 12 months) using departmental or outside resources and consumer-grade technologies. (1)
Yvonne Genovese, vice president at Gartner said ”One of the keys to using pace layering is to take a more granular approach to thinking about applications.  When classifying applications in pace layers, they must be broken down into individual processes or functions.  Gartner analysts said that one of the keys to developing this strategy is listening carefully to the way business people describe their vision for particular parts of the business. These categories of ideas include:
  • Common ideas — aspects of the business in which leaders are happy to follow commonly accepted ways of doing things that change fairly slowly.
  • Different ideas — aspects of the business in which leaders not only want to do things differently from comparable organizations, but also can specify the details of how the different approach should be taken, and can expect these details to change on a regular basis.
  • New ideas — aspects of the business in which leaders are thinking of an early stage concept, and are not at the point where they can be specific regarding the details of how things should work. (2)
By engaging in Pace Layered Application Strategy, DevOps practices, along with a strong Business Relation Management (BRM) process, we can realize the goals of collaboration and integration while using technology to automate the process of software delivery and infrastructure change, while providing a secure and cost-effective environment to support core business processes.


1&2 Source: Gartner - Pace Layered Application Strategy - http://www.gartner.com/newsroom/id/1923014http://www.itsmacademy.com/resourcecenter

Tuesday, April 18, 2017

Big Bang - DevOps

I learned about ‘The Diffusion of Innovation Theory’ in a DevOps Foundation training course.  I wanted to get my DevOps certification but more than that to learn about what makes a DevOps initiative successful.   When I mentioned the Diffusion of Innovation Theory to a coworker he said “It sounds like Sheldon talking to Raj on “The Big Bang Theory” tv series.  Although the name sounds Big Bangish the usage of this theory could be the real difference for success in any transformational change including DevOps.

To start let’s begin with the definition of DevOps. DevOps is a professional and cultural movement that that stresses communication, collaboration, integration and automation in order to improve the flow of work between software developers and IT operations professionals. Improved workflows will result in an improved ability to design, develop, deploy and operate software and services faster. That’s where this “Big Bang” or Diffusion of Innovation Theory comes in.   DevOps is a culture shift.

DevOps is a cultural movement that requires us to shatter the silos and to quickly integrate our teams to increase the flow of work from idea to end of life for the strategy, development, deployment and the sustaining of service over their life. Adoption of a new idea, behavior, or product (i.e., ‘innovation’) does not happen simultaneously in a social system. It is a process whereby some people are more apt to adopt the innovation than others.  Researchers have found that people who adopt an innovation early have different characteristics than people who adopt an innovation later.  Learning what those characteristics are and then how to apply the proper technique for each will help with the management of organizational change.

The Diffusion of Innovation is a theory that seeks to explain how, why, and at what rate new ideas and technology spread.  While most of the general population tends to fall in the middle categories, it is still necessary to understand the characteristics of a given target population. When promoting an innovation there are different strategies used to appeal to the different adopter categories.

Innovators – want to be the first to try the innovation. They are venturesome and interested in new ideas. These people are very willing to take risks and are often the first to develop new ideas. Very little, if anything, needs to be done to appeal to this population.
Early Adopters – represent opinion leaders. They enjoy leadership roles and embrace change opportunities. They are already aware of the need to change and so are very comfortable adopting new ideas. Strategies to appeal to this population include how‐to manuals and information sheets on implementation. They do not need information to convince them to change.
Early Majority – rarely leaders, but they do adopt new ideas before the average person. That said, they typically need to see evidence that the innovation works before they are willing to adopt it. Strategies to appeal to this population include success stories and evidence of the innovation's effectiveness.
Late Majority – skeptical of change and will only adopt an innovation after it has been tried by the majority. Strategies to appeal to this population include information on how many other people have tried the innovation and have adopted it successfully.
Laggards ‐ bound by tradition and very conservative. They are very skeptical of change and are the hardest group to bring on board. Strategies to appeal to this population include statistics, fear appeals, and pressure from people in the other adopter groups.

When promoting an innovation to a target population, it is important to understand the characteristics of the target population that will help or hinder adoption of the innovation. The Diffusion of Innovation Theory could be the “Big Bang” that you are looking for to ensure the success of your DevOps initiative.


Tuesday, April 11, 2017

Security in a DevOps Environment

Integrating Development and Operation teams as well as other functions that have previously been silo’d is key to any development project for all service providers today.   We hear a lot about this in DevOps training and certification classes.   What about security?  You may have heard the term DevSecOps.  This idea and term was coined to ensure that architects and developers include into our requirements and code those things necessary for security. Design architects will also want to ensure that security is integrated throughout the value stream of development, deployment and operations and it is done in such a way so that the complexity is as transparent as possible to the functional teams involved.   How can we do this without impeding our flow of work?    How can we still be able to meet compliance for legislative, legal or regulatory requirements relating to security?

This is where Automation comes in.  Collaboration and measurement are key values but automation is also needed to ensure success here. We hear a lot about Continuous Delivery and Continuous Deployment.  Those knowledgeable about this know that these practices include integrated/ automated testing at the same time as we commit code and complete the build.  We cannot simply disregard security. Developers, security architects and testers will be integrating the security requirements in addition to those required for the functionality of the application/code.   Simply put, in DevSecOps we are designing for security and doing that while we design and integrate the code for the functionality of a product or service.  To do this you will need to have clearly defined roles and responsibilities for integrated requirements, integrated development and integrated teams.

Developers, auditors and other members of this integrated system will need to be trained or retrained on how to develop secure code.  They will need to understand those elements required in the code to ensure it is resilient.  If the developers of an application know the security requirements prior to development, the code will look very different.   We no longer want to put security on as a wrapper after the code is developed.  Even though a single team may be responsible, different people in the team will assume different roles. The scope of their capabilities can be managed.  To do this organizations will need support for common DevOps toolchain environments and include security into each. 

For more information relating to DevOps and DevSecOps please see http://www.itsmacademy.com/devops

Tuesday, April 4, 2017

BRM Convergence

I remember reading a quote “Every business today is a technology company” or something close to that. As we move from business-IT alignment to business-IT integration and now convergence, it is becoming more and more critical to understand and manage both the business and IT capabilities so that integration of the business strategy, IT strategy and the IT portfolio are seamless.  In today’s business climate it is imperative that the IT organization not only understand what the business strategy is, but be able to initiate and deliver services that not only support it, but help to shape it.  The Business Relationship role, process and capability is integral in making that happen.

One of the tools that can be engaged to help facilitate this convergence is the “Business Capability Roadmap.   It is made up of three key components:
  • Roadmap Business Capabilities: Identifies how business capabilities need to change to achieve defined strategies.
  • Roadmap Enabling Capabilities: Identifies how provider capabilities need to change in order to underpin new business capabilities.
  • Assess Enterprise Opportunities:  Explores how new provider capabilities will be engaged across the enterprise.
The benefit that the organization derives from this activity is that we understand where the business is taking key capabilities over the next 3 to 5 years so that we can appropriately support its strategic objectives.  We can then ally business and provider processes, information, services and technology to a common vision and mission.  This will accelerate strategic thinking versus short term thinking. It drives the conversation forward to increase understanding between the business and the provider which results in the ability to identify enterprise opportunities more quickly allowing us to be more agile in the delivery of new or improved services.


For more information please see http://www.itsmacademy.com/brmp

Tuesday, March 28, 2017

Education in a Changing World

In years past you had to have some years behind you so that you could talk about the good old days.  Conversations would start with statements like “Remember when…?”   Today when a conversation starts with those words it could be a young person talking about how they did things last year or last month vs. how they go about their day to day activities today.
   
Things are changing so fast!  How does this affect educating and training learners and what needs to be tracked and recorded?  Certainly, not the same as it was a decade ago.

 A recent solicitation stated “Use of ed tech is skyrocketing, students on campus tote several devices each, but service needs range from high tech (wifi, connected classroom) to mundane (rat in the cafeteria, dorm toilet won't flush). All those needs have to be logged, serviced, tracked, reported on - hence the high demands on the platform used”.  Opportunity for bigger, better and more technology abounds!

The tools that we use and the infrastructure that supports them are dynamic and keeping apprised of them will have an impact on the value delivered through our colleges and training organizations.  No matter how quickly activities, lifestyles, viewpoints and technologies change, there are some things that stay the same.

Inspiration and Education are required elements for true knowledge transfer.  Inspiration will always be key in education.  To inspire means to fill an individual with the urge or ability to do or feel something, especially to do something creative.  What about education? According to WIKI, “Education is the process of facilitating learning, or the acquisition of knowledge, skills, values, beliefs and habits. Educational methods include storytelling, discussion, teaching, training and directed research. Education frequently takes place under the guidance of educators, but learners may also educate themselves. Education can take place in formal or informal settings and any experience that has a formative effect on the way one thinks, feels, or acts may be considered educational.” 

While Education and Inspiration might remain the cornerstone of teaching, the methodology of teaching is called pedagogy.  The methodology or the way we go about teaching and learning is changing and changing fast!  The tools used by learners, the tools used by teachers and the tools and technology to track and support them are all in a state of flux.

Knowledge transfer and educating learners when you get right down to it has many aspects that will not change.  Instruction delivered with passion and mission could trump the latest and greatest in technology when it comes to learning but the ability for educators and training organizations to keep up with the use of skyrocketing ed tech and the dynamic needs of learners will require both.
 

Tuesday, March 21, 2017

BRM, DevOps and Excellence in IT Service Management

To say that digital technology has changed the world is an understatement. Digital transformations are revolutionizing entire industries and reshaping every aspect of business. To stay competitive, businesses must accelerate the delivery of digital products and services. To meet business demand, IT organizations must accelerate the delivery of secure, high-quality and reliable software features and functionality (DevOps).

The thing about any transformation, whether it’s the digital transformation affecting the world, or the DevOps transformation affecting IT organizations and their business partners, is that it’s never only about the technology. A successful transformation requires shifts in peoples’ behaviors, mindsets, vocabulary, roles and reporting relationships. It requires changes to processes and to day-to-day operating procedures.

Perhaps most importantly, the ability to undertake and achieve any transformation is determined by whether, or not, the company’s leadership has articulated a clear business strategy and has fostered a culture that embraces innovation, collaboration, and experimentation, taking risks and learning from failure (The Third Way).

Here’s where Business Relationship Management comes into play. As a discipline, Business Relationship Management embodies a set of competencies (knowledge, skills and behaviors) that foster productive, value-producing relationships between an IT organization and its business partners. As a role, a Business Relationship Manager (BRM) is a link between a provider organization and one or more business units. BRM(s) work with business units to understand their needs and plans and to coordinate the delivery of IT services that meet those needs. Ultimately, BRMS help move the IT organization from being viewed as an order taker into a strategic business partner.
    
But herein lies the reality. Business unit leaders aren’t going to be willing to discuss strategic plans with BRMs until they can trust that the issues of today and this week (incidents, problems, changes, releases) are being taken care of. The road from service provider to trusted advisor to strategic business partner is built on a foundation of IT service management excellence.

The same can be said for DevOps. You sometimes hear that DevOps and IT service management (ITSM) aren’t compatible (but that’s another blog for another day). The reality is that organizations that are successfully adopting DevOps practices such as continuous integration, continuous delivery and continuous testing are performing ITSM processes. Those processes are just so streamlined and, in many cases, automated that people don’t even realize that they are executing ITSM processes.

Will excellence in ITSM guarantee the elevation of the IT organization to strategic business partner? Not necessarily. But BRMs will never get a seat at the table when strategic conversations are happening without it.

Tuesday, March 14, 2017

Why RCV?

I was recently asked the following: “I want to take the “Release, Control and Validation” (RCV) class.  As a Release Manager, I know it will help but I need to justify this for my manager.  What is the value of taking this class?”

Every organization can be effective with release and deployments.  What is needed today is for us not only to get the job done but to do it efficiently.  Efficiency infers that we deliver value, but that we design and deliver services, BETTER, MORE, FASTER THAN EVER BEFORE and at the same time we are being COST effective.

The role of Release Manager, although it is central to the release and deployment process, is much broader in scope than many organizations or managers realize.  This role in Best Practice is separate from Change Manager and from the actual Validation and Testing Manager or even the Change Evaluation role.   Frequently these roles will be assigned to one or more persons.  It does not mean that you have to open several new req's or that you will have to replace people.  What this does mean is that a clear and concise understanding of these processes, roles and functions must be clearly understood in order for organizations to really reap the benefits that they expect from change and release efforts.  Not only do we need to understand the dependencies, but also the workflow of how we can quickly interface with the various functional teams to respond quickly.  Without the proper knowledge and skill for these best practices, an organization could overtime improve but will be less likely to reap the type of optimization and benefits that they had hoped for. Everyone will agree that we can always do better with what we have.

The course Release Control and Validation (RCV) provides in-depth knowledge of the ITIL RCV areas: Change Management, Release and Deployment Management, Service Validation and Testing, Service Asset and Configuration Management, Request Fulfillment, Change Evaluation and Knowledge Management; most importantly the roles and the process interfaces and dependencies.  Best practice can help get the bigger picture, identify gaps, and allow for the practitioner to be enabled for success.   Business requirements are dynamic and we (throughout the design & delivery) must also have processes and models in place to meet those constantly changing business requirements.

In summary, the RCV processes, integration and knowledge enable:
  • response to CHANGING Business Requirements
  • consistent and Repeatable Workflow that result in and successfully deploy faster into the   environment
  • your staff and your organization for real success resulting in less rework and greater productivity
  • results in cost savings for the business
  • the ability to deploy changes quickly with less defects and therefore less business and customer disruption
  • risk reduction while complying with governance and audit requirements 
  • overall improvement in quality resulting in increased value for consumers

 For more information on Release, Control, and Validation:  click here