Showing posts with label cloud. Show all posts
Showing posts with label cloud. Show all posts

Wednesday, May 23, 2018

You Need to Know: Shadow IT

Troy Hunt just posted a new free Pluralsight video about "Shadow IT." That term sounds nefarious, but it's actually quite innocent. It's someone creates or uses software or a resource that hasn't been documented in the IT inventory and approved for use inside the organization. Because it hasn't been through the on-boarding process for IT resources, it also hasn't passed security checks.

Some examples include: A Google Drive or a One Drive to store or share files. A share drive with open access. Cloud services on Azure, AWS, Google Could, IBM Bluemix, etc.

What Are the Issues?

It's not that using these resources are an issue in and of itself; it's that they present potential security and management issues.


Because the security of "Shadow IT Resources" are unknown to the organization, they could open security holes. Those security holes can be either external (exposing information outside the organization) or internal (exposing information to unintended people inside). It may not always be a problem per-se, but either scenario could really cause problems for the organization. Those problems can result in loss of business, legal proceedings, and even cause the business to fail.

Web app services on Cloud platforms are designed to be open to the world be default. They can be secured by deploying them inside a VPC (Virtual Private Cloud) which is accessible from within the network only. This same concept applies to many other Cloud services.

Besides Cloud services, there are countless tools, games, and application that are easily accessible to anyone with an internet connection. Security problems unknown, these could contain malicious code which is designed to leak information


Besides the costs of recovering from an information leak, another potential cost concern is an unplanned expenditure. Particularly with cloud services since its relatively easy to create a new resource on a cloud platform. Cloud services are pay as you go so it would be a slow-burn rather than a fast explosion that leaked information would present.

This kind of issue is easier to resolve since all activities are logged and can therefore be monitored easily. Services like Alert Logic and Stackify give you insight into activities on the Cloud.

Scaling is another source of cost. Cloud resources are made to scale -  meaning new servers or service handlers are created to handle increased traffic. Configure scaling appropriately and set limits to ensure that a DDOS (Distributed Denial of Service) attack doesn't end up costing you a fortune overnight. For example: the cost difference between a single small AWS server and many XXXL servers is in orders of magnitude of 100x the cost.


Despite the aforementioned concerns, it's not worthwhile to be too restrictive when it comes to using the tools available. The trick is to find a path that's just right.

The Tale of Goldilocks According to Me

In the classic Goldilocks fable, Goldilocks happens upon a cottage in the woods. The cottage is the residence of three bears (papa, mama, baby). She "innocently" does a B&E (Breaking and Entering). Besides the unauthorized entry into the abode, she eats their food; sampling the porridge of each until she finds the one that's not too hot and not too cold, but just right! After that she samples the chairs. Baby's chair is just the right size, but she breaks it. Then she proceeds upstairs to the bedroom and tries all the beds: papa's is too hard, mama's is too soft, but baby's is just right. She falls asleep only to be awakened by the angry bear family returned from their morning walk ready to maul her. She barely escapes with her life after her little crime spree.


Besides the rampant crime in the story, Goldilocks has to try what's available until she finds what's right for her. Follow this practice, starting with most restrictive. However, do be open about the strategy so that those in the organization aren't taken aback by the sudden lock-down! Some of what exists in Shadow IT-land may be business critical! In that case a total lock-down would cause serious business disruption. Consider that they do lock-downs in prison when a fight breaks out...

Stay Calm and Keep Innovating

Another extremely important factor in applying the right level and doing so with care to respect the autonomy of individuals is the innovation factor. Theodore Henderson of the Forbes Coaches Council notes that "Innovation Is Crucial To Your Organization's Long-Term Success." He cites many success stories of innovative products that have lead to serious growth of organizations. One such example is GMail, which is the fruit of Paul Buchheit's 20% time according to (free time given for the purpose of innovation).

Disallowing the use of applications and services can seriously stifle innovation. It can do so in two ways:

1. Denying access to tools that can make people more productive.
2. Making employees feel less autonomous.

Autonomy is important to innovation which stems from motivation. Going into total lock-down mode can make people like they're under total external control which stifles their innovations and productivity. As a business model, that isn't going to go well unless you're business is 20th century line assembly.


While it may be natural to knee-jerk and enter into total lock-down, it's important to find the right level of control. The right level of control means keeping Shadow IT to a minimum and plugging security holes while keeping all employees on the same side as Info Sec and Governance.

Read Troy Hunt's post here:

Thursday, July 13, 2017

Managing Complexity in Today's World

Are business problems more complex today? That's the assumption I'm going to operate on - and I'm sure you'll find no shortage of sources on the web to back that up (empirical evidence aside). So let's assume that rhetoric for now in good faith and an appeal to common sense. Padding aside, that complexity flows through to the systems we create - the software included. In order to manage that complexity, we've become Agile.

I hear ya: "Not another article about Agile...". I know, I know.

But let me at least tell the story about what inspired this and then move on to the point. An IT professional (non-technical) and I started chatting and the conversation led to tools for automating business processes. I've developed on platforms and developed custom solutions for business process automation. Evaluating solutions can be a complex process in and of itself. The analysis process is fraught with uncertainty, broad (inaccurate) estimation, bias, and difficult to predict outcomes. Marketing (being what it is) definitely can skew the analysis. Heck, that's part of the duty of marketing! With proper marketing, sales is nothing but finalizing the deal that was already done through the marketing. So what does that have to do with Agile?

Agile is about being able to respond to change. In software, if we are truly following Agile principles and the practices set forth by the minds that solidified the movement, then we are designing and developing software that can respond to changes in the face of complexity. Lately, that seems to be the mantra of the business world as well - business needs to be Agile so that it can respond to changes in the complex market. As technology and automation have been evolving exponentially, so evolves the need for business to evolve to respond to those - among many other - changes.

Thinking about what this means in terms of managing change in the face of complexity and cost. In the software world, cloud computing has become all-the-rage for just those reasons. In the cloud, you pay only for what you use; changing and configuring resources is relatively easy; there are no data centers or servers for the business to manage. Good software design has been about responding to change for many many years, but now the infrastructure has caught up. It is a service rather than an internal resource.

Back to the topic of deciding on a platform...

Some platforms follow the cloud model - pay for what you use. Others - pay a big fee up front along with licensing and maintenance fees annually. Some platforms can respond to change - they are testable, debug-able, manageable. Others...not so much. Some platforms can handle some business situations easily. Usefulness is a function of cost v realization of value - as always, use the right tools for the job.

But whom should decide what the right tools are?

When you take your car to a mechanic - you may be paying for the service and it may be your car, but the mechanic knows which tools to use. Same with the surgeon, plumber, accountant, attorney, chef, construction company, or any other number of service professionals. Why should it be any different for software? Professionals know their craft. Business people know their business - and many know how to do software, woodworking, plumbing, some things legal, accounting, have dissected a frog - does that mean they should perform surgery? If you've replaced the float in the toilet, should you be replacing your own stack*? So who should decide which tools to apply in software development? Logically, it should be the professional software developer who knows their craft.

However, the situation changes when the cost exceeds the budget of the development department. Other levels of the business has to get involved in the decisions, there are politics at play, the tool may be oversold - then what? Now you've bought a tool without a use! So then you look for ways to use the tool to realize it's it's the non-tool user calling the shots (since they've put their money and reputation on the line) on which tools to use to do the job. Then partitioning of tool users happens - you have experts in such platforms. Someone higher up the food chain now decides which tool to use and assigns the problem to the expert(s) of that tool. The expert dutifully applies said tool to the problem (which of course is a problem that tool was designed to handle because when you only know how to use hammer, every problem is a nail).

What's the better model? Maybe that's better left to another post, but I'll give you a hint - there's no 01001001 in the solution.

*A stack is an air vent that allows the toilet to flush properly among other things; without it the suction would be a serious problem. Perhaps it gets blocked by leaves or a birds nest and you have some issues. They used to make them out of cast iron which is some really heavy stuff that can maim you if you don't know what you're doing. They've also used galvanized steel which rusts over time. That rust can also clog the stack. Replacement should be done by a professional only (no user serviceable parts inside).