What does it look like to deploy a DevOps project into Azure for a Java Application?

Introduction

A few months ago “Azure Devops Projects” was released. As I haven’t had the time yet to test-drive it, I was still sceptic towards the service from a naming perspective. In full disclosure, for me DevOps is about three aspects ; People, Processes & Products (“Tools”). The last part is typically, and maybe surprisingly, the most easy part to do. That being said, as I tried this service, I must admit that this service reduces the friction to set up an end-to-end project. This is where the Azure Devops Project shines! It guides you in a step-by-step manner to set up the end-to-end project for a variety of languages and deployment methods.

 

A brief walk-through

As we all know, the proof of the pudding is in the eating. So let’s see what the flow looks like in reality?

Best practices regarding the creation of an “RFP” (aka “Request for Proposal”)

The Overall Process

• Study ; The first step… Consider what you want to achieve and what’s life currently like. This might seem as a no-brainer, though you might be surprised how few organisations actually do this.
• RFI ; So you have a great idea? Fantastic! Now compare this with what is currently seen as industry standards and what are common solutions positioned by vendors. My advice here is not to differ too much from the ongoing standards, unless this is really ground breaking or market differentiating for you. Though, in most cases, you are just looking to keep your business running. In the latter case, keep as close to the standard as possible.
• RFP/RFQ ; So we know what we want, and what is possible at this point in time by the market. Let’s select our vendors from who we wish a clear-cut proposal. We’ll go more in detail about this phase later on… So don’t worry. 🙂
• Project ; Once the selection is done and contract negotiations are (near) closed, the project can start. This usually starts with a due diligence by the vendor to check if the assumptions / constraints are still valid.
• Operations ; A lot of people think that operations stops during this project. The reality is far from it, and that’s actually common sense! We do projects to enhance our operational baseline, but the latter is a moving target. We cannot freeze our business for half a year! So be aware of this…

Study
The first step before any project should be a “study”. Do a requirements analysis, update your views on the operational baseline and define the target flag of what you want to reach. Now you can do a fit-gap analysis and see what needs to be done. If the entire matter is way to big… Slice it into smaller / manageable chunks. In the past, we often saw “big bang”-projects which have shifted towards “Roadmaps”. In a Roadmap, the road towards the end goal is mapped via smaller / more realistic paths (projects). The conjunction of all these projects ensure that you reach your path. Though where it might be possible to enter all these projects into one RFP, in most cases it might be more interesting to spread them as your operational baseline is (with due reason!) a moving target.

RFI
Your job is mostly focussed to serving your internal business processes. It is not wrong to say that you are not an expert in the sector you want to purchase from. This is not something to be ashamed of! Though, be aware that your vendor IS an expert in the matter. During the “RFI” (Request for Information”) you are going to study the relative sector from which you are looking to acquire services/products. Research into the products and do not be shy to invite vendors over to discuss their products. Learn to know their (dis)advantages and how they can serve your business. In the end… always translate certain “features” / “technologies” into basic requirements. For instance ; IT Storage projects revolve around “capacity”, “performance”, “availability” & “integration”. Thin provisioning, snapshotting, deduplication, … all revolve around “capacity”. So do not be fooled by the nice “bling bling” that vendors portray and search for the essence of what you want to achieve. During this round, you will also define your list of requirements and selection criteria! So be sure to look for the elements that should compose these requirements/criteria.

RFP/RFQ

Phases

• Start-up ; Invite the vendors to take part and ask them to confirm. After receiving confirmations, send the RFP to all vendors at the same time.
• Round One ; During the first round, you will allow the vendors some time (typically one to two weeks) to process the RFP. At the end of that period, they will need to have sent all their answers to you. You will process these and provide all vendors with a list of all questions & answers. After which, you will allow them again a given period to adjust their proposal to fit these answers. After the deadline, you will do a “downselect” of the vendors to reach the number of vendors you want in round two.
• Round Two ; When going through the answers of round one, you will notice that there are fundamental differences between vendors. Now you will adjust your requirements to align all the vendors towards one target. In addition, you will invite the vendors to explain their proposals into more detail. This will give you a more profound insight into the reality of things. At the end of this round, you will once again to a downselect to reach the last contestants (typically two or three).
• Last Round ; At the beginning of the last round, be sure to provide the remaining vendors with a clear-cut baseline that everyone should meet. Now you do not want any structural differences between the parties anymore where the main focus will be around meeting the target and pricing. Clearly indicate that this should be their “Best And Final Offer” (“BAFO”), which will be presented at CxO level. At the end, choose the party which ranks the highest in relation to your selection criteria.
• Contract negotiations ; After the selection, contract negotiations will start. In some cases, an “LOI” (“Letter of Intent”) will be signed to create a non-linear relation between the contract negotiations and the project start.
• Project Start ; The project will start with a due diligence; Here an investigation will be done by the vendor to check if all the assumptions made (and agreed upon) are valid. After which the project will kick-off!

Be aware that these kind of processes can take up to half a year! So be sure to initiate them with ample time left before your deadline. Also be aware that these things will have a delay and in most cases this is caused by yourself! You still have your regular job to do… and you will get questions that you did not consider and need time to analyze.

RFP/RFQ Document Contents
So how should a typical RFP/RFQ document look?

• Management Summary ; Create a one-pager for executives from the vendors to read through.
• Context ; Why do you launch this RFP/RFQ? Provide an insight into your way of working/environment. How does this project interact with it?
• Timing ; Setup a clear timing table. Each phase should have a clear deadline… An RFP/RFQ is a project so be sure to manage it like a project. This is also important for the vendors to allocate resources towards the process of answering the proposal. It is in your best interest to ensure that they can prepare themself properly.
• Selection Criteria ; Always use (and communicate!) selection criteria. You, and the vendors, should know how you will quote their proposals and make the final selection. Be ware that these will become the core driver for the proposals! If you hand out more than 50% on price, then you will get skimmed down offers.
• Requirements & Product/Service/Project Definition ; Apart from the selection criteria, also be aware that the vendor will provide you the most slim answer to meet your requirements. So if you didn’t define it, you will not receive it! Do not assume anything… This might again look like a no-brainer, though… 😦
• Constraints ; Actually, these can also be considered requirements… Yet be sure to state that a vendor should take certain constraints into account. Do you require a certain transition / honeymoon period? Do their employees need to have NATO-clearance, …
• Pricing Table ; You do not want all vendors to provide their own pricing table… You will not be able to compare apples with oranges. So provide your own pricing table and adjust it according to the feedback from each round. In fact, your RFI phase should have already provided you with ample information to create a pretty stable pricing sheet.

The DTAP-Street : a phased approach to a development / deployment cycle

The acronym DTAP finds its origin in the words Development, Testing, Acceptance and Production. The DTAP-street is a commonly accepted method to have a phased approach to software development / deployment.

A typical flow works as follows :

• Development – This environment is where the software is developed. It is the first environment that is used. Changes are very frequent here, as this is the first area where creativity is forged into a product.
• Test – A developer is (hopefully) not alone. In the test environment, the complete code base is merged and forged into one single product. The first attempts at standardization and alignment towards the future production environment are made here.
• Acceptation – Once the development team feels that the product is ready, it will be deployed to acceptance. This is a look-alike of the production and used by operations as a staging environment for production releases.
• Production – The real deal… Here the product surely needs to be ready for prime-time.

Sometimes the following are also added ;

• Education / Training – Sometimes a dedicated environment is needed where people can test drive the software in a safe sand box. Due to efficiency reasons, this environment is often time shared with acceptation.
• Backup / Disaster Recovery – Disasters can happen… Therefore some disaster recovery plans may rely on a dedicated backup / disaster recovery location.
• Integration – An environment that is sometimes located between “Test” & “Acceptance” as an intermediate step to test certain partner integrations. Just as with the “eduction” environment, this environment is often time shared with acceptation.

What are the most commonly used formations?

• Live – Production – Many companies rely solely on a production environment. The risk reduction is often neglected in favor of the cost benefit of having one environment.
• Staging – Production/Test – If no real customization are done to the implemented software, then two environments may suffice.
• DTAP – Development/Test/Acceptation/Production – Once customization hit… then a full DTAP-street is needed to reduce the amount of risks involved with software development.
• DTAPB – Development/Test/Acceptation/Production/Backup – This is an enhanced DTAP-street that is capable of doing a disaster recovery. (Sidenote ; The Test/Development environment is often shared with the backup location. This provides the advantage that the resources of the Test/Development can be sacrificed during a disaster.)

What Code / Data flows occur between the environments?

• Software Versions – Software releases go from Development to Test to Acceptation to Production… The timing varies from the chose release management cycle, though typical times are as follows ; Development (Continuous Builds), Test (Daily Build), Acceptation (Once per quarter, three weeks before production), Production (Once per quarter)
• Data – Data flows in the opposite direction as software versions. Data is taken from production and copied to Acceptance / Test / Development. Depending on the environment (and relative security compliancy), the data may be anonymized or even reduced to have a representative production workload of a limited size.

Lingo Explained : Stakeholder

Stakeholders… Who are they?
Stakeholders are people who have key roles in, or concerns about, your project/architecture/…

What’s the use in identifing stakeholders?
This is a discipline called “Stakeholder Management“. Here you are going to identify the most powerful/influencial stakeholders early and ensure their input is used to shape your project/architecture/… This to ensure a smooth change.

A basic tool for this is the “Stakeholder Map” where you document the stakeholders, their key concerns & identified class.

Lingo Explained : ROI, NPV, IRR

When talking about projects, you often see the following terms popping up ; ROI, NPV & IRR. Yet what do they mean?

ROI

• Abbreviation : Return On Investment
• In Short : The ROI will give you an indication how fast you will have a return on your investment. It’s mostly expressed in a period of years, when calculating with costs related to a year.
• Wikipedia : http://en.wikipedia.org/wiki/Return_on_investment
• Formula :
  

  return on investment = (gain from investment – cost of investment) / cost of investment

• Video : Youtube

NPV

• Abbreviation : Net Present Value
• In Short : NPV compares the value of a dollar today to the value of that same dollar in the future, taking inflation and returns into account.
• Wikipedia : http://en.wikipedia.org/wiki/Net_present_value
• Formula :
  

  

• Video : Youtube

IRR

• Abbreviation : Internal Rate of Return
• In Short : The IRR will indicate the “interest” you get from an investement. It’s often used as a metric to see if money shouldn’t be kept with the finance institution instead of within a (risky) investment.
• Wikipedia : http://en.wikipedia.org/wiki/Internal_rate_of_return
• Formula :
  

  Check here…

• Video : Youtube

And how does that related to decision making?

Devops : What kind of animal is it, and what dogfood does(n’t) it eat.

Wikipedia
Where I believe from that cornerstone of my hear in this role, I often see it misinterpreted or even abused… So today we’ll talk about the “devops”-animal, and what it should be doing. Let’s first take a glance at Wikipedia (as it’s always a nice reference) ;

DevOps (a portmanteau of development and operations) is a software development method that stresses communication, collaboration and integration between software developers and information technology (IT) professionals. DevOps is a response to the interdependence of software development and IT operations. It aims to help an organization rapidly produce software products and services.

So the essence of the role (and yes, it is a role, not an animal, sorry to disappoint you) lies as a bridging function between “Development” & “Operations”. This statement is backed up in the Wikipedia article too ;

DevOps is frequently described as a more collaborative and productive relationship between development teams and operations teams. This improved relationship and collaboration increases efficiency and reduces the production risk associated with frequent changes.

The role of a DevOps professional has similarities to that of a Chief Engineer within the Toyota Production System. Such persons have responsibilities for the project’s success, but no formal authority over different teams involved. This requires technical knowledge in order to convince managers of the needs. Company executives can make convincing the managers more effective by formally endorsing the role of the Chief Engineer.

Many organizations divide Development and System Administration into different departments. While Development departments are usually driven by user needs for frequent delivery of new features, Operations departments focus more on availability, stability of IT services and IT cost efficiency. These two contradicting goals create a “gap” between Development and Operations, which slows down IT’s delivery of business value.

What does it bring?
The article visualizes the role as following ;

Where this might seem a bit different from the “bridging role” as just mentioned, imaging the “Quality Assurance” as the role you often see with your Architect(s). When we go to the stereotypes of each departement; we see that development is typically the team that wants to “inovate”, where operations is the team that wants the least amount of change in order to provide the needed stability. The devops will take both worlds into account. (S)he will introduce things like “High Availability”, “Scalibility”, “Performance”, “Security”, “Data Integrity”, “Monitoring”, and so on from the Operations world. On the other side, (s)he’ll also introduce versioning, automation, release management, and so on from the development world.

So what isn’t it?
Think about the following pitfalls ;

• Devops is not a team…
• Devops does not live within one technology team. (S)he stretches accross boundaries!
• It’s also not the chinese volunteer that will be scr*wed with all your releases.

I think with those statements a lot of companies their interpretation of “Devops” went down the drain…

Still confused?
Still not sure what it is? Check Patrick Debois’s slideshare presentation on Devops, as that one is spot on!

Managing Team Changes within a Project

Source : Tips for Managing Your Ever-Changing Project Team

“Make Newcomers Welcome”
Some basic points we tend to forget, yet they are truly important!

• Assigning a peer as a mentor to each new team member to help them with acculturation
• Providing basic educational materials about how your project management process works
• Taking time to explain core concepts in meetings instead of assuming everyone is up to speed already
• Encouraging new members to ask clarifying questions either during or after each meeting if they don’t understand something

Address Conflicts Immediately
Sadly enough, seen this one “live” too many times before…

If a team member comes to you with a complaint about a coworker, take it seriously. Often, employees will wait until they are really fed up before they go to management to ask for help with resolving a conflict. When their concerns are dismissed instead of being addressed, they will transfer some of their anger and resentment at their coworker onto the manager who ignored their request for help. You don’t want to become the enemy.

As with everything, don’t let things wait, and get them addressed quickly. And hope you are in a position to manage the situation or to get the escalation right on!

Tucker!
Don’t forget the “Forming, storming, norming & performing“-phases! This cycle restarts every time a new team member joins a team.

Fluent change management in Project Management

Source : How To Be A Change Agent In Project Management

Talk the Talk You are more likely to gain support from upper level management if you can speak their language. There are many aspects of project management knowledge that overlap with other disciplines. Communicating in a way that demonstrates your understanding of a peer’s area of expertise will help them trust that you know what you are doing in your sphere of specialization. So, when you speak to Accounting you might pepper your conversation with terms like short term ROI and amortization. Just be careful not to use jargon unless you really know what it means. If you don’t use terminology correctly and in context you will simply end up looking foolish.

Big Picture/Small Picture Be aware that not everyone wants or needs to hear your grand vision for creating positive change through updated project management methodology. You should develop two spiels. One is for people who like a lot of context. Diagrams showing how project management is related to other business processes and how changes will affect the company over time are useful for these audiences. – Others want you to cut to the chase since they only care about how your suggested changes will affect them or their department directly. For these individuals, a short bullet list of what you need from them is the best tool you can use to gain support. It keeps things simple and shows that you understand the value of people’s time.

Showing Value Besides communicating what you need from others, you also need to show specifically what you are going to do for them in return. For example, a discussion with the HR director needs to focus on human capital management. This is the time to make realistic predictions about how greater project management efficiency will translate to lower labor costs. You can also seek feedback regarding how your new way of handling projects may impact employee engagement. – For IT, you could talk about how using a particular version of project management software would relieve them of the burden of ongoing development and maintenance. When you are negotiating with stakeholders, be sure that what you are offering actually has value to them. If you aren’t sure what they want, ask. Then, you will know where you stand in negotiations.

Projectmanagement for dummies

Nah, we won’t be doing a book review here… instead this’ll be a small post describing the essentials of project management. Here are the … elements which embody project management :

• Definition : You should have a complete list of items you should deliver and which you should NOT deliver! Look at it as a contract, where both parties agree upon a delivered item.
• Changes : Try to keep changes to a minimum. Yet when they are presented, make sure to document & agree upon them between Project Manager (responsible) & Sponsor (customer).
• TODO : Make sure you have all deliverables noted down, so you can tick those who have been done in order to know which still have to be done.
• Time & Money : The aspects time & money need to be stated & respected as well.
• Stakeholders : Make sure you do not forget anyone (really, anyone!) who is related to the changes you’re creating. Next up, make sure you handle (communication!) them well.

Now the above can be done in any methodology; Prince, PMBOK, … it doesn’t matter. It’s up to you to know how much “protocol” is needed to do the task. Some firms require a lot of stagegates where some rather like the informal approach. See what works best for you, and good luck!

Project Management Best Practices

TechRepublic featured a good article about “the 10 best practices for successful project management“. These steps give you a good outline of the things you should cover. Have fun reading!