Archive by Author |

More SLA Questions..

Can my words have footnotes, please? – Amy Harbottle

This past week I was interviewed for the upcoming http://www.servicetechsymposium.com/ this year.  I always take every opportunity to speak or teach because it forces me to really focus on the areas that I am exploring with others.  One of the most popular subjects in recent times is the SLA, that is why I have chosen to spend a lot of time on it.

We have a problem and it is a serious one, consumers are not controlling the market.   I understand that the idea of this doesn’t make much sense but it is the reality and we need to know what we can do about it, if anything.   We also need to know what questions we should ask from the boardroom to the lab.

How much do you pay for gas today?  When you go to the doctor’s office are the prices on the wall like McDonalds?  How about your dentist?

How many times have you installed a piece of software and scrolled down through 60+ pages (like Apple) to use install it or use the product?

Lets get this straight… you go someplace or purchase something and you have NO SAY in the conditions of the exchange other than if you don’t like it you don’t accept.  What if your husband or wife agreed and you didn’t know?  What about your children?  They click faster than you.

I remember when you could go into a store and negotiate a price on an item and the conditions of sale.   You can still do that!  We just have either forgotten or our children don’t know.  This is very important because it directly correlates to your ability to make choices on what you are willing to purchase and what you aren’t.  If I told you that somewhere in the agreement that you didn’t read it says “If xxx.inc finds out that you have died, xxx.inc has the right to recover software sold under licensing and any hardware or media that software resides on”  Would that be ok?   Read some of these agreements.

This applies to the service level agreement as well.   This is critical because lawyers are not making these agreements on your behalf but they are making these agreements on behalf of the service provider.   It is like going to court without representation against the legal mafia.

Last year Amazon had a service outage that put companies down hard but it didn’t violate any SLA and further there was no remedy for these companies ( http://cloud-computing-today.com/2011/04/24/why-amazons-cloud-computing-outage-didnt-violate-its-sla/)

Ray Wang http://www.forbes.com/sites/ciocentral/2011/04/25/mondays-musings-lessons-learned-from-amazons-cloud-outage/ writes:

As calmer heads prevail, most CIOs, business leaders, and analysts realize that:

  • Cloud outages are rare but can happen. While most organizations can not deliver 99.5% up time let alone 90% performance, disruptions can and will happen.  The massive impact to so many organizations last week highlights potential vulnerabilities of betting 100% of capacity in the cloud.  More importantly, it showed that broad adoption does not equate with bullet-proof reliability.  Most organizations lacked a contingency plan.
  • Cost benefit ratios still favor cloud deployments. For most organizations, the cost of deploying in the cloud remains a factor of 10 cheaper than moving back to the traditional data center or even a private cloud.  Capital costs for equipment, labor for managing the data center, excess software capacity, and the deployment time required to stand up a server create significant cost advantages for cloud deployments.
  • Current service level agreements lack teeth and should be improved.Most organizations lack teeth in the cloud/saas contracts to address service level agreement failure.  Despite all backups and contingency plans, clients should consider scenarios where core business systems go down. What remedies are appropriate? What contingencies for system back up are in place.   Who is responsible for disaster recovery? Will the vendor provide  liability and for what?

The Bottom Line: Proactively Account For Breaches In Service Level Agreements In SaaS/Cloud Contracts

Organizations should protect themselves from future breaches through a combination of contract provisions and contingency plans.  Here are some suggestions recommended to clients:

  • Apply provision from the SaaS/Cloud bill of rights.  Though written in late 2009, this document remains a best practices guide to SaaS contracting.  Key provisions to apply include: Quality guarantees and remuneration, stipulate data management requirements, on-going performance metrics
  • Include service level agreements with teeth. Credits for free licenses for down time sound good on paper. In reality, down time when critical systems fail could result in massive financial losses.  Contracts should apply risk on the potential business loss.  Some clients include a provision that identifies compensation for a percentage of average daily business revenue during the time period of down time.
  • Reevaluate your Amazon deployment strategy. Believe it or not, Amazon technically did not violate its service agreements.  To deploy a true backup strategy, organizations should add copies of their server instance in multiple regions and data centers as an added layer of protection.  This ensures that a proper fail over occurs even if multiple regions experience outages.
  • Implement a real disaster recovery strategy. The Amazon outage exposed that many start ups failed to have a disaster recovery strategy.  A number of solution providers now provide cloud disaster recovery.  More importantly, these providers can recover physical or virtual machines in a cloud within minutes.  Whether organizations can fire up a backup server in time remains the open question.

Think about this! 

Your business is YOUR responsibility.  How many organizations are responsible for more than just themselves?  Local, state and federal government are moving into cloud strategies, banks and financial institutions are making groundbreaking moves on cloud computing and finally medical communities are moving “to the cloud.”

My doctor is a really cool guy and I trust him when he tells me that I should eat right and exercise but I don’t want him putting my medical records in cloud services that he doesn’t understand.

Cloud SLA (Government / Defense)

I teach a cloud computing course for Thomas Erl @ Arcitura from time to time and the question that always comes up is the one about service level agreements.   It is a complicated subject that does not get enough attention in our industry.  I am presenting some of the discussions that we have had in class and some of the questions asked all relative to cloud computing and mostly aligned to the defense industry.    This is part of an SLA series of blogs to get people thinking about their requirements and to understand what an SLA can do or not do for a business.

Today I will share a short story .

It was 5:00 PM on a monday afternoon,  a routine procedure on a patient in London turned into a catastrophic challenge requiring expertise from across the pond.    Dr.  Jack Ash is a leading Gastroenterologist living in Ontario, Canada.   Dr. Ash received a call asking if he could help the patient in London.   Dr. Ash has extensive experience with remote surgery a relatively new practice taking shape using cloud oriented services.   Dr. Ash is using IT services provided by the hospital in Ontario.  The services in London are with a different hospital and a different IT service provider.   The configuration of the services look very similar to this (see figure 2) http://www.ncbi.nlm.nih.gov/pmc/articles/PMC1356984/

The SLA looks something like this IT_Service_Level_Agreement_Publish_To_Customers.   Dr. Ash didn’t have much time, he needed to act fast.   He ran down to the office and coordinated all of the requirements with the remote team in London.   This situation had been discussed before and the staff had practice with dummies and cadavers.  Fortunately for Dr. Ash he routinely performs procedures like this in Ontario between hospitals often.

The stage was set, the anesthesiologist had the patient stable and all of the supporting staff acted as planned.   Due to the situation and set backs some time had gone by and the procedure took place closer to 8:00 PM .

Dr. Ash started the robotic services and invoked various commands over the network.  At first the procedure was going well, there were some minor fluctuations with bandwidth but nothing major.  In order to make sure that the network connectivity was consistent Dr. Ash asked a staff member to call over to his local IT and make sure QoS was turned on.   The helpdesk reported back quickly that all available resources and network traffic managing the robotic services had priority on the network.   The procedure continued and Dr. Ash was noticing severe latency through his video stream.   He had to act fast to finish the procedure and just as he was finishing the final maneuvers, the robotic arms lost connection.  Luckily the original staff working on patient x were in the room for Dr. Ash to talk through the final moments.

What happened?  Why did the arm lose connectivity?  How did the SLA help?  How could the SLA have helped?

Although this story was not real, the technology is real and the fact is that medical practitioners are doing something like this today.   Why did the arm lose connectivity?  I’ll give you a hint, there was a soccer game at Chelsea http://www.chelseafc.com/ and there were a lot of people in London very interested in that game.

There are various reasons for the potential failure of service.   The problem is that most people focus on what technology can do as opposed to understanding where it make sense to use services like this and where it makes sense not to use these services.   There are plenty of business cases that could have created a more stable environment but more often than not businesses choose to go head first into situations like this.   It seems like a great idea and they even had an SLA!  I wonder what that would have done for patient x had this person died.

These are some of the concepts that we will need to explore further.  I will put together some defense oriented generic scenarios for thought.

 

 

Cyber Reporting

Cyber Security is just like any other security “everyone’s responsibility” but where do you go to let someone know there is a problem?

…going to the Dept of Homeland Security (DHS) provides the following options for reporting cyber related incidents:

  • Report Cyber Incidents
  • Report Phishing (US-CERT)
  • Report a Computer Incident (US-CERT)
  • File a Complaint (OnGuard Online)
  • Report a Cyber Vulnerability (e-mail)

http://www.dhs.gov/files/reportincidents/cybersecurity.shtm

The FBI link is: http://www.fbi.gov/about-us/investigate/cyber/cyber

Focus is:
(FBI) …lead(s) the national effort to investigate high-tech crimes, including cyber-based terrorism, computer intrusions, online sexual exploitation, and major cyber frauds. To stay in front of emerging trends, we gather and share information and intelligence with public and private sector partners worldwide.

In Depth
Key Priorities
* Computer Intrusions

* Innocent Images: Online Predators

* Anti-Piracy/Intellectual Property Rights

* Fraud: Internet Crime Complaint Center

Initiatives & Partnerships
* Cyber Action Teams

* Computer Crimes Task Forces

* Identity Theft

* InfraGard: Protecting Infrastructure

* National Cyber Investigative Joint Task Force

* National Cyber-Forensics & Training Alliance

* Strategic Alliance Cyber Crime Working Group

THE SLA (Part 1)

This past week http://www.cloud-council.org/released a practical guide to cloud SLA’s.    It is a good guide that looks at 10 steps to evaluate cloud service level agreements found here (Cloud SLA).

Online you can find various calculators and planning tools to help identify and define the various properties and areas of concern with SLA”s .

What we don’t see a lot of and I will start pull information together on and consolidate, is the implications of international law with respect to cloud computing.

What happens when you do business with China? http://doingbusinessinchina.theatlantic.com/

Does the SLA specify where cloud service transactions will take place?  Should it?

What kind of legal implications are there doing business in the cloud?

What are the costs of having legal representation overseas?

What about downtime?  How much will it cost to have more than one company with managed services?

How many companies have lawyers involved during the evaluation and purchase phase of acquiring cloud services?

How many companies have shadow IT involved in cloud services without even knowing the implications?

What about the US Government?  How many experts are actively engaged at the program or project level in understanding the implications of cloud resources?

Over the next few months I am going to put together some short blogs asking some of these questions and looking to see what I can come up with from the cloud consumer perspective.

We need to understand what legal questions to ask as well as the technical questions.   SLA’s are heavily weighted to the providers today and that will need to change in order to meet the needs of service consumers.

Take a look a these consideration from cloudbus

What it does say is you can terminate the agreement, what it doesn’t say is what happens to your business or your work.

Cloud Software License Agreement -(Altered from here)

Bloodthirsty Cloud License Agreement

————————————-

This is where the bloodthirsty license agreement is supposed to go,explaining that Interactive Cloudflow is a copyrighted service licensed for use by a single person, and sternly warning you not to use it with more than one person explaining, in detail, the gory consequences if you

do.

We know that you are an honest person, and are not going to go around sharing services of Interactive Cloudflow; this is just as well with us since we worked hard to perfect it. While you may understand that you do

not have the right to do anything with our service.

We have the right to do anything we want with your data and whatever resources you place on our servers. What is even better is that you have no idea who is looking at your data outside of the permissions you have agreed to. Our administrators, managers and engineers including anyone we describe outside of those people can get to your information without you knowing. That is acceptable to us.

If we find value in your data or “software code” we will take it and resell it at our discretion. We will also do our best to figure out what information that you place on our services will benefit our business and we will use that to potentially undermine your business.

At no time will we offer you any protection but we guarentee that your services will have an uptime of 99.999% without fail. If for some reason the service goes down, you can easily reach us at the beach or in my house. I will be there, just call.

Reblog Scott Suhy (Capitalize or Expense R&D)

Scott always has something of value in his posts.  This is a recent one that I would say is a great value.

http://scottsuhy.com/author/scottsuhy/

If you run a startup that does software R&D you will eventually be engaged in a discussion about capitalizing or expensing research and development costs.   Here are a few good reads.  If you see others with differing options please send them my way.

http://www.anderson.ucla.edu/faculty/david.aboody/software_AL.pdf

http://raw.rutgers.edu/docs/intangibles/Papers/In-process%20RDto%20capit.pdf

Columbia

http://www.nysscpa.org/cpajournal/2003/0703/dept/d074603.htm

Thinking about Grams

Image

 

Hey folks! I would like to introduce you to Dorothy.  Some people called her Dot but I called her Grams.  There is too much to say about her in a blog but I felt like talking about her today and so.. 

I knew her all of my young life into my early adulthood.  She passed away 11 years ago but she is always around.  I think we are who we are by genetics and by environment combined but what we achieve may be more about those who know us better than ourselves.  Of course everyone is different but in my case I always had an interesting supporting cast.   I have had the luck and blessing to have people who believed in me when I didn’t know to believe in myself.   My grandmother was one of those people.   She always told me that she believed in me, even when I was at my worst.  She taught me the value of strong trust relationships long before there was a book by Stephen M.R. Covey.    

She always told me that I have the potential to do anything.  To be a good person, you have to understand the differences between right and wrong.   You have to do what you say and keep your promises.   So… I hope to live up to her expectations and I am committed to doing my best to be a good person.  To do what I say I am going to do, to say what I mean and to value people and build trust and maintain that trust and help people where I can.   Thank you Grams! 

 

Same conversation over and over p30pl3 1st t3c4 2nd !

“Seek out the good in people” On Joy,  H. Jackson Brown jr.

Someone had to write a book to remind us.   Everything we do is tied to people, everything we touch is tied to people.   Everything you use, build from, build for, design, draw, implement, and write is tied to people.   If there were no one to read there would be little reason to write.

Wake up.  

This past week at the old store I used to work, I heard a story that they are changing the sign again.   A friend said “Don’t worry nothing to see here, move along.”     He was saying this as if he were the person in charge of course.  He was frustrated.   Leadership today is done behind closed doors and through email, behind the veil of technology.  It is a technology first approach.

Every day I practice looking for the good in people.   I know people matter.  I know that trust is key and further that a trust deficit will cause catastrophic failure.  If you are a developer using scrum, it is fundamentally about trusting your team.  If you are a manager, you are only a manager because you have a team.   All of the leadership books tell you that there is a difference between a leader and a manager.  Why does this point have to come out over and over?  Because in practice there is a failure to lead today.   Technology is king and people come second to it.   We are becoming slaves to the machine.

Just remember this simple thing no matter what you are working on.

“People first”  

Put it on a tee-shirt, put it on stationary, always remember and never forget.

 

Scrum for everyone, except it’s not.

I recently took the 2 day Scrum Alliance ScrumMaster course and I am openly more confused today than I was before I took the course.

ScrumDev PDF

My position is simple, if we don’t have these discussions and this dialogue Agile will be akin to SOA.  What happened to SOA?  Ask Ann Thomas Manes SOA is dead long live….   Of course SOA is not dead, but I sure don’t hear much about it anymore like I used to.

Back to my class.  I liked the trainer, he was cool.  I think he was close to my age or somewhere near there (let us say born in 1970 something).   He had cool hair, it was like this.

He had some cool skinny jeans on that my 16 year old son would wear if he was a sk@t0r or something.   He had mad cool tat’s that if he waved his arms fast enough around while raving would spell out some far out words with meaning or produce a crazy angel.  (If you don’t get what I am saying think of this)

He had years of experience as being a regular project manager, developer and all around IT guy.   He went from the boardroom to the playroom, where the dumbassery of waterfall is stabbed in the heart by the agile sword of success.   You may wonder why I am going through this whole description and so I will tell you.  I liked the guy, he was smart but he presented a culture aligned with this practice known as Scrum.    I wrote down a lot of what he said (this was training) and he did tell us to “empty your cup”  Here is the story you can click past this if you are not interested.

Empty Your Cup


A university professor went to visit a famous Zen master. While the master quietly served tea, the professor talked about Zen. The master poured the visitor’s cup to the brim, and then kept pouring. The professor watched the overflowing cup until he could no longer restrain himself. “It’s overfull! No more will go in!” the professor blurted. “You are like this cup,” the master replied, “How can I show you Zen unless you first empty your cup.”

People’s reactions to this story:

“You cannot learn anything if you already feel that you know.”

“Preconceived ideas and prejudices always prevent us from seeing the truth.”

“You should open your mind before you open your mouth.”

“The master is trying to tell him to ease back and relax. The professor is too anxious about the whole thing.”

“Some people want to be taught everything in one sitting. It’s not possible.”

“This story proves to me that you have to unlearn before you can learn.”

“We shouldn’t get too wrapped up in one aspect of life. If we do, we close ourselves off to new experiences.”

“Even though you may be full of knowledge, you should always be open to the fact that there is still more to learn.”

“I bet the master did that just to shut the professor up!”

“If you want to learn, you have to shut up and LISTEN for a change.”

“We should be open to the views of others, and accept them as their own. Treat each opinion individually, and don’t just add it to your own.”

“Sometimes another person has to catch you with your guard down in order to teach you something.”

“The professor’s understanding of Zen is too intellectualized. The master is trying to point him towards a more intuitive understanding . If you’re too intellectualized about ANY subject, often you miss the boat.”

“I would tell this story to anyone who believed something about me that was untrue.”

“I think the master was trying to show him that when you can no longer take it is time to give – and you must sometimes give in order to receive.”

“This professor probably doesn’t really believe in Zen. His prejudices are preventing him from seeing clearly. This is what the master is trying to show him.”

“Too much of anything is just too much!”

“I don’t think the professor’s reaction indicated that he had a closed mind. It was perfectly normal. Wouldn’t you do the same if someone was spilling tea all over the place?”

http://users.rider.edu/~suler/zenstory/emptycup.html

SO.. I did (if my friend Wednesday tells you otherwise she is mistaking me for someone else).   I then held out my empty cup for some knowledge and here is what I heard.

  1. Scrum is cool – if you practice scrum you are a cool rugby like player, you will be revered for being a hottie and all those around you will say things like “Oh ScrumMaster you are so awesome, I want to be like you.” In other words  (there is a culture involved)
  2. Scrum is only (REALLY) effective if people are in the same room . “If you can’t hear someone grunting when you are talking to them, you probably aren’t practicing scrum right.”
  3. Some stats as  I wrote them down and recorded them 1 in 10 agile teams are successful. About 40 percent of teams practicing scrum are effective or are doing it right. (http://blogs.pmi.org/blog/voices_on_project_management/2012/01/4-metrics-to-help-spot-trouble.html)
  4. If scrum isn’t working for you it is because you aren’t doing it right.  You need to hire an Agile Coach to come in and get your organization right.
  5. Waterfall is good for people that never want to make changes ever. Agile is good for people that always want to make changes always,  except when you are in the middle of doing something and you can’t change.
  6. The ScrumMaster has a lot of work to do but they really shouldn’t be involved in the work itself.
  7. “As a ScrumMaster if people are talking to me and I want them to talk to each other I turn my back on them.”
  8. Once you get certified as a CSM (Certified Scrum Master) you can go for a CSP (Professional) and then on to take a bunch of other scrum tests from other organizations and you can be a Scrum trainer which is equivalent to a Phd.
I have written enough for this entry but there is more to come.  If you disagree with what I wrote it is only because you are reading my words and which according to (http://www.minoritycareernet.com/newsltrs/95q3nonver.html) is only 7 percent of communication.
More to come.. but for now take a look at this link on Agile software development methodologies. 
http://agile.dzone.com/articles/software-development-methodolo

Agile Experts Follow Up

A few posting back I challenged the Agile community to bring to light their process and methods.   My blog is posted on Twitter, LinkedIn and a few other places, at the very least a few thousand people get notified of an update.  A few folks in the community responded but I would like to repost Dave Lamp’s comments here because he has a deep understanding of people, process, methods and use of tools from a military leadership perspective, a government contractor perspective, and a government civilian perspective.    Change has to come from a cultural normalization with practice.   A faster more effective and efficient approach to development requires TRUST.   If we were to analyse my blog, the word that would be used most across every post would be TRUST.   It is central to all that we do and it is critical that we work to gain and manage our trust relationships carefully.    Here is Dave’s comment :

You’re not wrong in this assessment of agile, but probably are pointing out clearly the fact that most program managers are the sad and unwitting victims of the dreaded and highly contagious condition known as REIFICATION–the mental state where one believes that something is real when it is only an idea. So we continually talk about about agile acquisition, “rapid” fielding, crowd sourcing, social networking…ad nauseum…as a means of making ourselves believe that these words are making something happen by our use of them, rather than doing what they would logically demand–using Scrum techniques and shortening delivery schedules, for example!

The biggest danger of this linguistic condition is that a chronic malaise sets in usually accomplanied by a fetid and seemingly endless discharge of…PowerPoint slides! The person so infected will exhibit an emotional and tersely worded unwillingness to entertain their worsening infection, citing such things as Forge.mil or Govloop as illustrations of how the Defense Department is already even now moving into this rapid fielding of agile acquisition capability. The fact that their projects do not use these methods, that no process exists for sharing specifications for web service development does not prove their disease, since such outcomes are “not in their swim lane” or that their program was not funded to “boil the ocean” or “solve world hunger” which such actions would certainly illustrate.

So….how do deal with the worsening condition of governmental IT professionals? I believe that what someone must do is to create a simple, safe and secure method of creating web services, just as has been done with the Ozone Widget Framework for visualization services. If a web services development toolkit (WSDK) could be found on Forge.mil as an “app” for regular warfighters to build a “data-as-a-service” container that could be used by anyone for a particular function, you would catastrophically transform the Defense Department’s web service development process. We would begin to see a rapid migration to agile development by end users who would be able to take their spreadsheets, their Access databases and store them as a service for others to consume as a reliable and accountable source of specific information about a particular function, location, mission or task. As “controlled unclassified information” (CUI) data services proliferated, leaders would then demand for similar web services on other classification levels. It would be success without fighting, a way of winning recommended by none other than the ever-quoted Chiense general Sun Tzu!. After all, producers have no incentive to do this since they are all too often trapped by the “cost, schedule, performance” tyranny of the old-school program manager. So they have to console themselves that someone will eventually give them a contract to do things this way. However, all too often the old-school program manager has a doppelganger at the contractor’s management who see no value in a course of action that would lower billable hours, shorten the billable schedule and “undoubtedly” destroy overall IT development performance! NOT!

If I were able to do it myself, I’d build such a toolkit out of Google Apps that connected to JackBe’s mashups, OWF widgets and SharePoint portlets. However, I’d like to recommend it to you as one that could be done by the wise and capable readership of this blog! This could become a shared “trailblazer” project worth doing in Forge and could be a shining example of how this collaborative environment was designed to work–safely, securely and sanely in a sweetly agile way! Let’s do this!

 

 

Follow

Get every new post delivered to your Inbox.

Join 184 other followers