devopsy.kinsta.cloud

Tag: collaboration

SDN has a lot to offer to DevOps

When discussing DevOps it’s natural to focus the attention on the one operations team that focuses on application infrastructure. But when you start digging in to DevOps and its applicability to all four operations groups you’ll find that technological shifts in the network – like software-defined networks (SDN) – are just as important to the overall success of DevOps-related initiatives as the spread of software-defined operations going on across the application infrastructure.

One of the intersections of network and app infrastructure operations is around speed. Not just speed of deployment of services supporting applications, which is critical, but also the resulting speed of the application itself. Application performance management (APM) is a less often mentioned concern of those looking at DevOps but it is one with which developers and app infrastructure operations alike are very interested in not just monitoring and measuring but improving.

But here’s the thing: the relationship between the app infrastructure and the network are intertwined when it comes to application performance. Measuring and monitoring in the app infrastructure is all well and good, but it is impacted by network performance. And vice versa. Technically speaking, the app infrastructure folks are going to end up tweaking things like TCP; changing window sizes and timeouts in order to improve poorly performing apps. And they should, as TCP is highly tunable and one of the primary means of changing the performance behavior of an application.

But tweaking TCP has an impact on network performance. TCP is a reliable transport protocol, meaning its particular about thinks like packet order and its very responsible about making sure each and every packet is received. When one isn’t, it resends it. And resends it. And resends it. Retransmit storms contribute to the congestion of the network, which in turn contributes to the need to retransmit, which in turn… well, I think you see the Catch-22 here. While the app infrastructure team is pointing fingers at network operations, the network operations team is pointing fingers at the app infrastructure team.

Both are equally responsible for the problem.

SDN promises, in part, to address the problems associated with speed. Both speed of service deployment (through operationalization) as well as speed of delivery, i.e. application performance. SDN will, ostensibly, provide the means to both recognize application specific performance requirements and adjust, as necessary, the delivery of application data through the network in order to meet those requirements. But what it also implies is the ability to provide visibility into the reason why new routes were necessary. There are plenty of reasons an application might initiate a retransmission storm and some of them are related to the application platform (TCP problems), others to the client or the Internet itself, and still others to the network. Being able to quickly identify what is causing a degradation in application performance gives everyone the ability to react and resolve the problem faster.

That goes to MTTR (mean-time to resolution), a key DevOps-related metric.

But for all that to happen, there has to be some collaboration (sharing) going on between network and app infrastructure operations. There has to be less finger pointing and more question asking going on between the two, and the sharing of collected performance data across the entire application delivery chain – from network to platform to the app itself. SDN provides a means through which such measurements can be obtained and shared with other systems – and teams. This ability is important. Puppet Labs 2014 State of DevOps Report named it a “top practice” correlated with MTTR, and CA’s latest report indicated 19% of organizations adopting DevOps have experienced “Improved quality and performance of our deployed applications.”

Monitoring and measuring application performance is a key component of DevOps, and yet a significant portion of that performance is dependent on and related to the network. Which means app infrastructure operations can’t measure or address poor performance without understanding the network’s contribution to the whole.

SDN “apps” can be one way in which app infrastructure and network operations can gain insight into how apps are performing and how the network is impacting that performance – for good or bad. Whether it’s simply having the data to share or providing an interface into the network to gather the data, SDN has the potential to enable greater collaboration across network and app infrastructure teams.

That makes it an excellent player in the wider ecosystem of tools and frameworks that support the need for monitoring and measurement associated with DevOps initiatives.

November 6, 2014
Moving Security To the Left In a DevOps World

Moving security to the left has become a coined phrase meant to describe the process of getting the security team involved earlier in a process. Most typically, the phrase is used in conjunction with IT or software development projects. One of the top suggestions for ensuring security in a DevOps world is to move security to the left in the process tool chain. But what exactly or how exactly can you move security to the left?

Grab that Open Seat

The new DevOps process pipeline created an opening for a seat at the table for security. Prior to DevOps, the development team owned the entire pipeline from plan to release. The Ops team would historically receive the release from over the wall and then be responsible for the deployment and operating the software inside the production environment. With the Ops team joining forces with Development in the process pipeline, that has opened a proverbial seat at the table. What I’ve started to witness are security teams taking advantage of the musical chairs to quickly grab the open spot.

Taking a seat at the end of the development pipeline is not enough. Too many security teams are still being relegated to positions too late in the process. While running pen tests and security code reviews after a release is better then nothing, its still not ideal. Security needs to find ways to add value to the process so they can act as a force for positive change instead of the after thought.

Threat Vector Analysis

Threat vector analysis is part science and part art and part trying to guess uncertainty. What is certain, however, is that most developers would rather be spending their time writing new functionality instead of trying to understand how an attacker could be break their code. The security team could offer a tremendous service to an organization by offering their expertise in this area.

Continuous Integration Security Testing

Continuous integration is a key component of DevOps. The security team can leverage the development chain to insert early yet important risk control tests. Those tests could be for example static or dynamic code analysis. Other tests could be simple yet known vulnerability checks in included libraries. The OWASP introduction to testing guide lists a plethora of application security tests that should be checked often and early.

Author Micro Security Services

Think about how great it would be if there was a group who specialized in authoring and delivering security related services into your application? Proponents of services models generally promote splitting the development team up into groups that are organized around business capabilities. For example, there are separate development groups for UI, middleware and DB. What’s missing in most of those models is who is responsible for security services such as authentication, authorization and audit. Security has an opportunity just waiting for them to add incredible value while also ensuring the security services used pass muster.

Summary

Where we once had Ops fighting their way to be part of the entire development process, we now have security trying to do the same. Ops managed to garner their way into the club by coming to the table with invaluable skills and resources. Now its up to security to present their creative sweet spot in order to secure their own seat at the table.

Further Reading

Andi Mann on Ensuring security and managing risk in enterprise DevOps

October 1, 2014
My Little Operations: DevOps is Magic
Bear with me, it will all make sense in the end.

If you aren’t familiar with My Little Pony: Friendship is Magic (because you don’t have a child who watches it over and over and … well, over) let me sum up for you:

There’s a pony who knows something horrible is coming. She wants to stop it. She’s instead sent by management to make friends, which seems to her to be ridiculous in the face of a looming catastrophe. When that catastrophe happens, she and her new “friends” (her coworkers) set off to find the elements of harmony – the only thing that can save the world. But lo and behold, evil destroys the elements. Or so it appears. See, it turns out that the friends are the embodiment of the elements of harmony and through their friendship they create the most powerful element of them all: magic. Together, they are strong enough to defeat the evil and restore harmony to the data center. Err, I mean, to the pony world.

If we take this and apply it to operations, you should start seeing some common themes. Primarily, you might note that, like magic, the ultimate goal of DevOps – agility – can only be “achieved” by the collaborative efforts of the other elements of operational harmony, namely predictability, repeatability, composability, consistency and stability. It isn’t a tangible “thing” you can buy, it doesn’t come in a can, it can’t be delivered by Amazon.

These elements combine and, when practiced cooperatively, create a new element: agility. Which is a significant goal of DevOps based on a variety of surveys. Oh, it’s always stated a different way: we want to improve the time to market, increase frequency of deploys, reduce downtime due to errors, etc… but in general, these all fall under the need to enable the same level of “agility” in operations (and the network, but that’s a different discussion) as is present in application development today. Fast and frequent change to match application (and business) changes. Agility.

But agility, like magic, can only be achieved through friendship (or as we’ll call it, collaboration). That’s because agility requires a variety of separate concerns (qualities) to come together in concert before it can be realized:

Agility (DevOps)
- Predictability (time to deploy, important for planning)
- Repeatability (of process to other applications)
- Composability (reuse of steps in other processes)
- Consistency (important for maintainability and trust in process)
- Stability ( of the overall infrastructure )
That’s why it’s important not to look at DevOps as a set of tools. There are multiple facets to DevOps that can be enabled by tools and enhanced by tools and even monitored by tools, but DevOps is not the tools themselves any more than the elements of harmony were the gems the Little Ponies sought. The real magic of DevOps is the agility created by collaboratively working together to bring each of the elements into operations. Without stability, have you achieved agility? Or is it really chaos?

If you can’t repeat the process (apply it to other applications) have you really achieved agility or just strictly codified a single deployment? If the process isn’t consistent, and gives different results have you realized an agile environment or anarchistic one?

These elements are necessary to achieve real agility of operations, and those elements can only come about in a cooperative environment in which they all work together.

DevOps, so it seems, is magic after all.
September 16, 2014
Collaboration in Progress: Making DevOps a Reality

Everything on your company’s DevOps checklist is accounted for. It’s got the vision and the talent. It’s identified the problems and mapped out a solution. It’s got a culture that allows the flexibility that such a plan requires. Now’s the time to put the plan into action and let the benefits begin.

The truth is that it may not be that simple. A great plan won’t mean anything unless everyone understands how to achieve it. And whatever a company’s DevOps strategy consists of, collaboration is the key to making it a reality.

Collaboration is at the heart of DevOps. It’s even conveyed in the phrase itself. No matter the size of your company, this new process of teamwork and transparency relies on combining strengths between Development and Operations to achieve goals that otherwise wouldn’t be possible.

Breaking Silos with a Full-Circle Approach

With one department responsible for writing code and another responsible for implementing it, silos can naturally form as each group focuses on its job. This kind of structure is what commonly gives rise to software deployments taking longer than they should and even little or no communication taking place between the two departments.

DevOps has come about as an antidote to these kinds of siloed situations in which inefficiencies and a lack of teamwork are the norm. Yet for DevOps to take off, both Development and Operations have to participate fully and understand that collaboration requires equal cooperation from both sides. Such collaboration has to take place not just at certain stages, but throughout the life of a project. When each team is invested in the effort by providing feedback, helping identify future problems and continually learning from day-to-day deployments, a company has a great chance of seeing benefits from these new collaborative efforts. Without complete buy-in from everyone, the process will never get off the ground.

The Evolution of Collaboration

Just as DevOps is about moving beyond the assembly line process of software development, the concept of collaboration itself is evolving. DevOps-style teamwork can consist of more than breaking down the silos between different teams. In an agile infrastructure, team members can wear different hats and swap responsibilities depending on the demands of the day. Instead of a scenario in which people work on single specialized tasks without any interaction with the larger group, you’ll have contributors who can play multiple roles within a team and understand how this boosts productivity for the entire company, rather than just a single department. It’s possible that a team member can function as a developer one day and then work on deployments another. Through DevOps, an organization can advance beyond one-dimensional departments and one-dimensional contributions.

Real-World DevOps Teamwork

For many within the IT industry, DevOps is already a working reality. Breaking silos and becoming more agile are goals for companies that know how increased collaboration can help their business. A good source that lays out some first-hand experiences of DevOps practitioners can be found in the recently published Rackspace e-book, The DevOps Mindset: Real-World Insights from Tech Leaders. It features interviews with IT experts who discuss what led them to adopt a DevOps approach and recommendations for those interested in a new agile approach to software deployment.

When discussing the importance of agile teamwork, James Kenigsberg of 2U remarks that, “To achieve true DevOps collaboration, you need your employees to really think and act as one, not just be merged together in name only.” As a provider of online university programs, 2U faces a huge demand for quick, dependable deployments and underwent a transition to increase teamwork at the company. “We had to flip the model,” Kenigsberg explains, “from the idea of personal heroics and siloed responsibilities to real, cross-functional collaboration.”

Jim Kimball of fund administrator HedgeServ reiterates this cross-departmental approach. “Repeatability and scalability are our business,” he explains. “The capabilities that DevOps gives us directly enable this by encouraging collaboration within the organization to come up with better solutions.”

Forging a Partnership Between Dev and Ops

Assembling a skilled and talented group that will be the envy of your industry is the ideal every company would like to have. If you’re able to gather a team that’s the IT equivalent of the X-Men, it’s not enough to just assemble that talent and assign them siloed roles. Without frequent teamwork, not only will company goals become difficult to achieve, but solving problems will be nearly impossible.

When Development and Operations see themselves as working in partnership with each other, the foundation for greater collaboration will be in place, and company goals, such as greater speed to market, increased productivity and an all-around agile performance, will be within reach. With the right mentality, DevOps can be an evolutionary step in company functionality and reach new levels of efficiency that otherwise wouldn’t be achievable.

September 16, 2014
DevOps makes coding more social, social coding makes better code

One of the main principles of DevOps is to break down silos. What’s more like a silo than the image of a lone developer, shutting himself off from the world in order to code more and interact with people less? “I’m just here to write code and that’s all I do.” There’s nothing collaborative or DevOps about that scenario and unfortunately, it’s one that is all too frequent within organizations.

Enter social coding. This is a concept that didn’t exist twenty, or even ten, years ago and one that continues to grow in popularity. At its essence, social coding is an approach to software development that puts the focus on formal and informal collaboration. There are many benefits to social coding but the most important is probably the opportunity it presents for mutual growth and learning. Developers are allowed to collaborate in an environment that fosters discussion, creation and sharing.

When talking social coding, you can’t avoid a mention of GitHub. Take everything you love about your favorite social network and then apply those same ideas to a code repository. That’s basically what GitHub did, and continues to do, with much success. You can create a profile, follow or message someone, see what others are doing with their code (or yours) and even go so far as to subscribe to RSS feeds of activity streams. GitHub started to take off a mere five years ago and is now held up as one of the more successful examples of how social coding can be commercialized.

Companies like GitHub and SourceForge are leading the way in revolutionizing how developers commit and share their code but the foundation of social coding still rests with code review in a public forum. As Mark Chu-Carroll puts it…

“If you’re programming and you know that your coworkers are going to look at your code, you program differently. You’ll write code that’s neater, better documented and better organized — because you’ll know that people whose opinions you care about will be looking at your code. Without review, you know that people will look at code eventually. But because it’s not immediate, it doesn’t have that same sense of urgency, and it doesn’t have the same feeling of personal judgement.”

What’s next for social coding? After it’s start in the open source community, this is one idea (like many others) that is heading towards the enterprise market. Companies are beginning to recognize that even internal projects can be managed and treated as open source efforts. From wikis to crowdsourcing, there are many ways that the enterprise market can take advantage of social coding. The end user is the one who stands to benefit the most from such a change.

Dave West, a Principal Analyst at Forrester Research, has this to say about social coding:

“We’re social animals, and the development of stuff tends to be social in nature. We think a better way of thinking about it is as social development. It’s not just about coding; it’s about enabling business change and delivering business value in a social way. It will be interesting to see how companies broaden the idea from social coding to social development. Social coding is a fundamental change.”

April 25, 2014
DevOps developers; don’t be a DevGoof

There was a lot of brush back last week over Jeff Knupp’s post about how DevOps is killing the developer. Frankly I wasn’t shocked by Knupp’s opinion that developers “are the dentists in the dental office”. In my 30+ years of involvement in the IT industry my experience is that developers often think of themselves as the only smart person in the room. Often times that is the reason they are are the only person in the room, lol. The fact is many developers relate better to code than to people. For me all this talk about DevOps killing the developer is akin to saying power steering killed the driver. Just because you can do more with new technology, does not mean one dies, one just has to pivot and in this case become business social.

Now the sociable part may be the problem. Sometimes I feel that DevOps is trying to create a love fest between Ops, Developers, QA, security and the rest of the IT stack. While they may not have to love each other, I do think they all need to be nice to each other as opposed to ignoring or just going around each other, as was all too often done in the past. A common scenario I have seen for example is for developers to rollover Ops by stating this is mission critical for the business. These tactics will no longer work to let developers have their way.

Developers need to realize they need to become a normal part of the business social structure. They will be required to talk and work with people, not throw tantrums when they don’t get their way. Left unchecked, certain developer personality types can sabotage your project, or worse, make themselves no fun to work with. I am sure we have all met and unfortunately had to work with people like that. In my career, I’ve encountered virtually every personality type. In fact, I’ve also knowingly hired all of them. They know who they are; they are the developer that if challenged or worse accurately taken to task for lack of being part of the team; quit cause they can’t manage the confrontation, thus interpersonal stress. In the old days they would not come out of their house for weeks continually playing Leisure Suit Larry, if your not familiar with it Google it

I remember one of my good friends telling me this story that sums this whole developer persona issue perfectly. This company, we will call DevGoof, was a well funded start up. Every quarter they held a meeting with all the employees to let them know how the company was doing. Most employees had some kind of equity play in the company, so everyone was incented and theoretically interested in company performance. Several quarterly meetings came and went and not one developer showed up. Eventually DevGoof management got concerned and called a mandatory meeting for all developers’.

DevGoof management put out some pastries, juice and coffee for the brain trust. Then proceeded to tell them why these meetings were important to them and their fellow employees. Notably pointing out how it is not just about them but also about the rest of the DevGoof team. This meeting went on for about one hour and not one developer asked a question. So eventually this meeting was over and everyone went back to developing. The next morning, about 50% of the developers quit and some in a not so professional fashion.

The moral of this blog is the DevOps is going to force the development community to become more interpersonal within the business environment. This will lead to personal success within the new world of DevOps. The DevOps Developer/Engineer that can demonstrate leadership and compassion for team will be the one leading the DevOps way within the organization. Don’t be a Devgoof!

If you would like say something; email parker@devops.com and don’t forget to comment here.

April 23, 2014
Merging creation with operations: facilitated collaboration enables continuous delivery
So much has been written lately about the challenge of improving IT agility in the enterprise. The best sources of insight on why this challenge is so difficult are the CIOs, application owners, ecommerce and release engineering executives, and VPs of I&O, grappling to change their organizations right now.

At a conference I attended recently, I met two Fortune 100 IT executives from the same company: one the head of development and the other operations. Their story is emblematic of just how hard this is in the real world. As interesting background, both the development and operations leaders were childhood best friends, participated in each others’ weddings, and spend time together socially on an almost weekly basis – but by their own admission, even they couldn’t get effective collaboration and communication to work between their two organizations.

The lesson learned from this example is that the DevOps collaboration and communication challenge cannot be solved by sheer will, desire or executive fiat. Instead, you must breakdown the barriers that inhibit collaborative behavior and facilitate new ways of communicating and working together. The old standbys of email, instant messaging, SharePoint sites, and conference calls don’t cut it.

The challenge of two opposing forces: Dev and Ops

Imagine yourself helping your children put together a new jigsaw puzzle. Each time you turn your attention to a specific piece, the kids reorganize what you have already completed and they add new pieces, but in the wrong places. For sure, three pairs of hands can be better than one, but they can also create chaos, confusion and significantly elongate the completion of the puzzle.

The collaboration challenge in the DevOps movement is grounded in this analogy. How do you get multiple people working together across teams, locations, and time zones to build and get things deployed faster without chaos, confusion, and delay? How do you get these teams to speak the same language and collaborate together with a singular purpose when their priorities and motivations are so different?

Faced with this challenge, it’s easy to see why many organizations have stayed in their comfort zone of ‘waterfall’ releases and keep the number of releases per year small. The issue is this method isn’t meeting the demands of the business, the market and competition. As a result, more and more business leaders are going around their IT organizations. Options like public cloud, SaaS, open source tools, skunk works IT and outsourcing are making it easier for them to control IT decisions and implementations within the business unit or department itself.

So let’s dive deeper to understand the two forces at the heart of the issue: development (focused on the creation or modification of applications to support a business need) and operations (delivering defined services with stability and quality). It appears these forces are working in opposition, but both groups are focused on doing what leadership asks of them.

Developers tend to think their job is done once the application is rapidly created, but it’s not because no actual value has been delivered to the business until the application is operational and in production. Operations is severely disciplined when services experience performance and availability issues and they have come to learn that uncontrolled change is the biggest cause of these issues. As a result, operations teams often believe their number one job is to minimize change to better control impact on performance and availability. This causes operations to be a barrier to the rapid change required to give the business the speed and agility it needs.

Critical to enabling DevOps is an explicit recognition of this situation and the ability to link discrete phases of the application development and operations lifecycle to enabling ‘fast, continuous flow’ – from defining requirements, to architecting the design, to building the functionality, to testing the application, to deploying the application to both pre-production and production environments and to managing all the underlying infrastructure change required for the application to operate efficiently and effectively in all environments.

Why current approaches don’t work

There are several challenges in achieving this ideal.

1. Developers hate to document (can you blame them?), and, when they do, their communication is in a context they understand, not necessarily empathetic with the language that operations speaks. The view from operations is that the documentation they receive is incomplete, confusing, and/or misleading. With the rapid pace of development, this challenge is getting worse with documentation becoming more and more transient as developers “reconfigure the puzzle” on the fly.

2. Today’s operations teams typically take responsibility for production environments and their stability. That means there is usually a group wedged in between the two – the quality assurance (QA) team. QA’s job is to validate the application works as expected and often they require multiple environments for each release. This group is typically juggling multiple releases and is, in essence, working on and reconfiguring multiple puzzles at the same time. The challenge of keeping QA environments in sync with both in-process releases and production can be maddening (just talk to any QA leader and they’ll tell you first-hand). The documentation coming from development is inadequate, and the documentation coming from production is often no better, since most operations teams store much of their most current information about configurations in personal files or simply in their brains.

3. The ad hoc handoffs from development to operations and QA take time away from development’s primary mission: creating applications that advance the business. Some suggest developers should operate and support what they code in order to reduce handoffs and the risk of information distortion or loss. A fundamental risk with this approach is opportunity cost. Does a developer really understand the latest and greatest technology available for infrastructure and how to flex and scale those technologies to fit the organization need? Do you even want them to or would you rather they be coding instead?

4. Others have suggested that Operations move upstream and own all environments from dev to QA to production, and treat configuration and deployment scripts as code just like a developer would. This may sound like a good option, but it can create a constraint on your operations team and cause valuable intelligence to become hidden in scripts. A particular application deployment could have one or more software packages required and potentially hundreds of different configuration settings. If all that information is embedded in a script, how will other team members know this if they go to make a change to the underlying infrastructure to apply a security patch, upgrade an OS version, or any of the other changes made in IT every day?

Real DevOps transformation doesn’t mean that you give everyone new jobs, instead, it’s about creating an environment where teams can collaborate together with a common language and where information is immediately available at the point of execution and in a context unique to each team.

A better way forward

In The Phoenix Project, written by DevOps thought leaders Kevin Behr, Gene Kim and George Spafford, the authors promote the need for optimizing the entire end-to-end flow of the discrete processes required for application delivery – applying principles as they achieved agility in the discrete manufacturing process.

Manufacturing in the 1980s resembled IT operations today, employing rigid silos of people and automation for efficiency and low cost, but this became a huge barrier to the agility, stability and quality the market demanded. They learned if you optimize each workstation in a plant, you don’t optimize for the end-to-end process. They also learned that if quality and compliance processes were ancillary to the manufacturing process, it slowed things down, drove up costs and actually decreased quality and compliance.

Successful manufacturers brought a broader view and optimized end-to-end flow rather than operate in a particular silo. They also brought quality and compliance processes inline with the manufacturing process. By addressing quality and compliance early in the cycle and at the moment that an issue occurred, cycle times decreased significantly, costs plummeted and quality and compliance increased dramatically.

These same principles can be applied to IT resulting in:
- faster time to market;
- greater ability to react to competitive pressures;
- deployments with fewer errors
- continuous compliance with policies; and
- improved productivity.
DevOps can best be realized when IT operates in a social, collaborative environment that ensures all groups are working with a visual model in their context with the necessary information from downstream and upstream teams, as well as in collaborating with relevant experts at the moment when clarifications are needed or issues arise.

To merge creation with operation, the core idea behind DevOps, requires a cultural change and new methods in which cross-functional teams are in a state of continuous collaboration as they deliver their piece of the puzzle at the right time, in the right way, in-context with the other teams in other silos. Operating something that never existed before requires documentation so that operations teams have the information they need to manage change with stability and quality.

With more modern collaboration methods, self-documenting capabilities are now possible as development, release and operations do their respective jobs, including visualization of documentation with analytics and with the perspective and context each team needs to effectively do their job downstream. These types of capabilities will transform organizational culture and break down barriers to collaboration that impede agility, stability and quality.

Is this simply nirvana, unachievable in the real world? No. Manufacturing achieved the same results by applying these principles; the fundamental point being made in The Phoenix Project.

The goal is not to write code or to keep infrastructure up and running, or to release new applications or to maintain quality and compliance. Instead, the goal is for IT to take the discrete silos of people, tools, information and automation, and create a continuous delivery environment through facilitated collaboration and communication. This will drive the cultural and operational transformation necessary to enable IT to respond to business needs with agility while ensuring operational stability and quality.
April 21, 2014
Technology’s effect on religion

Today being Good Friday, with Easter being Sunday and in the midst of Passover; it is a time for reflection. Instead of thinking about DevOps, today I ponder life and religion. What comes to mind is the future of religion in these technological times. The number of Americans with a religious affiliation continues to decline, less and less of us make an appearance at a Synagogue, Church or any house of worship for that matter. In my childhood we would at the very least make an appearance a few holidays a year, notably at the annual pancake breakfast.

From the calculator to the computer, from mobile devices and the Internet, advances in technology are creating monumental changes in our lives and in turn the way religion is practiced. The universal acceptance of mobile devices, like the iPhone and iPad, is provoking a profound social change. The dependence on these devices is eliminating the individuals need for traditional religion and going to traditional houses of worship. The problem is, without the traditional religious brick and mortar upbringing, the youth of today forgo a key element of the religious experience. Religion was never just about a supreme being, the social gathering and interaction of those with similar beliefs and values is also a critical part of the experience. Religion is losing the youth.

It seems there are now thousands of apps which allow parishioners to bring Bible quotes, Torah-chanting practice and Buddhist prayer wheels anywhere, anytime day or night. My concern is how many of our youth are downloading religious apps as opposed to angry birds. The challenge is how to mobilize religion while still achieving all the religious personal support and socialization benefits that are realized from real life interaction in attending a place of worship. Is the virtual congregation a realistic way to gather people and practice religion? I have a hard time thinking the young will embrace religion without the real life experience which creates the feeling of being at peace with oneself.

The virtual congregation will be effective fill in for those who have already experienced religion in the traditional sense. Worshippers who cannot find their way to their house of worship for services will pray online with their fellow believers via the latest technology, confident that the other worshipers are doing the same on their devices. How powerful that will be is the question, it has been relatively effective via Television. But those are already followers seeking religious celebrities, not new believers.

There is no denying religious leaders who conduct services via technology to a geographically wide spread audience will notice a significant difference in how worshippers experience the event. Religion is very much an emotional event and technology can be a non starter for the holy rollers. Gathering around technology in smaller groups may be an answer.

The religious apathy of the young produces a serious problem for religious leaders looking to grow shrinking congregations. The lack of formal religious upbringing has lost many of the young and younger worshippers that do exist expect any religious event to embrace technology use. Device multitasking has become such a pervasive part of their life that quiet, hard cover book based religious ceremonies seem awkward and therefore not compelling.

Technology may represent the end of traditional religious worship, and the beginning of a new age of worship, the form of which no one can reasonably predict or control. The bottom line is if you look at technology and say how does this change people going to house of worship? You miss the point, because religion is a much deeper set of beliefs. The question is without new young followers, what does the future hold for organized religions?

If you would like say something; email parker@devops.com and don’t forget to comment here.

April 18, 2014
Why Vertical Collaboration Matters for DevOps

Vertical collaboration is defined by Rick Defour as a team of people working interdependently toward a common goal for which they are all mutually accountable.

Now that everyone is clear on the importance of collaboration and the different types, it’s time to delve into the importance of one type of collaboration in particular: vertical. Vertical collaboration is defined by Rick Defour as a team of people working interdependently toward a common goal for which they are all mutually accountable. You can find examples of vertical collaboration in educational settings where teachers of different levels work together to insure student success and in manufacturing settings where the supplier & retailer can better leverage themselves to enhance the bottom line for both.

When you think of vertical collaboration in the tech space, the example of a dev team pushing out code is a good one. Each dev has a different area of specialty but they must work together in order to implement the new feature. Taking this into consideration then, it’s easy to see why a vertical collaboration tool has to be easy to use and not create any new boundaries. The more vertical a collaborative tool is built, the more useful it is to real people.

The problem, of course, is that many companies view all collaboration tools as vertical. They only want to spend money on one tool so they pick the horizontal one (thinking that it’s the one more people will use) and it turns out to not actually be helpful to anyone. So that’s when companies start adding to their toolbox and then end up with a hodgepodge of tools. Instead of making their collaboration process more effective, they have made it more convoluted.

I created VictorOps because there was no existing vertical collaboration platform for DevOps. Going into it, I knew I was solving a problem I’d had at a number of previous companies and therefore already knew the exact requirements needed. The collaborative platform would have to be mobile first, would have to allow for synchronous engagement while enabling asynchronous problem solving and would have to give all participants symmetric access to information from their enterprise monitoring platform.

What I realized after creating VictorOps and using it to solve our own internal issues is that vertical collaboration gives team members the opportunity for scalable “leaning in” while also providing the freedom to lean out to reflect. What’s not to love about that?

April 17, 2014
Not all collaboration types are equal

Talking about collaboration in general terms is easy. I’ve done it and so has everyone else. It’s time now to dig deeper into the specifics of collaboration, meaning the different types – asynchronous vs. synchronous, vertical vs. horizontal – and how different companies fit into the magic collaboration quadrant. And yes, the quadrant is indeed magical.

Let’s start with the two types of collaboration that are time-relevant, asynchronous and synchronous. Asynchronous collaboration takes place outside of real-time. The best example of a ubiquitous asynchronous collaboration tool is email. You send an email and the receiver has time to digest the information. The drawback to asynchronous communication is that it’s inadequate as a means of communicating a sense of urgency. You have to wait for someone to respond to an email and that lack of immediacy can cause damage in troubleshooting or problem solving situations. Email replies tend to include the original message for context because you can’t rely on the timing of the message to keep the context.

On the other side of that collaboration coin, you have synchronous collaboration. Synchronous communication takes place like a conversation and more closely resembles a face-to-face interaction. A chat session is the ideal illustration of this concept. The obvious benefit to synchronous collaboration is the ability to send and receive information right away. This adds to the feeling of immediacy and tends to provide a more effective means of working together to solve issues in real-time.

Now that we have that covered, it’s time to move to the other defining aspect of collaboration: whether it’s vertical or horizontal. Vertical collaboration consists of problem solving tools that are domain-specific. An example of a vertical collaboration tool is one built for certain parts of the business like Salesforce for the Sales & Marketing teams or Rally for the development team. Horizontal collaboration consists of non-domain specific tools, meaning that they have potential use across all teams of an organization. Project management tools like Campfire or remote meeting solutions like Join.me or WebEx are examples of horizontal collaboration tools which tend to be widely adopted but lack the ability to really go very deep in helping in a domain-specific way.

Check out the quadrant I created to better show where different companies currently fit into the ever-growing collaboration landscape, based on the definitions provided above.

When looking at the state of collaboration tools, it’s interesting to note where most companies land within the quadrant. Why so few vertical synchronous ones? I’ll answer that next time.

April 11, 2014