Without question, technology is fundamental to successful organizations. Technology has transformed administrative tasks, our access to information, and how we connect with each other. Software as a Service (SaaS) platforms are revolutionizing workflows and the relationship between business and IT users. The unprecedented ease of implementation and increasing utility of these applications have created the opportunity for parallel technology stacks to operate in the shadows. The shadow IT landscape opens the door of possibility; however, we know that magic comes with a price.
What exactly is shadow IT? It could be a messenger app or voice over IP (VOIP) service , physical storage like flash drives, cloud storage like a Google Drive or Dropbox, planning calendars, writing services, or automation tools like Excel macros, Flows and PowerApps. Shadow IT is classified as an IT system built and used within an organization without explicit organizational approval.
Modern cloud enabled organizations are operating in an era where the internet browser is the ultimate technology platform. All your data, on any device, from anywhere; just add the internet. We live in a time where digital technology tools are not new and, in some cases, the applications we use have seen numerous refreshes and iterations over our organization’s lifetime. These legacy systems still deliver critical services and require regular maintenance to ensure they still are functional and secure. Younger generations are far more tech savvy, and decision making on IT systems is becoming far more distributed as organizations experiment with structures that drive more agility, creativity, and collaboration. End users are driving development and implementation or in the case of shadow IT, completely circumventing their IT department.
With no or low barriers to entry, business users can quickly create disorganized and fragmented IT infrastructure. Redundancy and security vulnerabilities pose significant challenges for IT professionals as business users experiment and deploy solutions for their workflows. Like a sugar rush, the quick productivity gains can evaporate in a crash. The inflexible nature of legacy systems and siloed IT departments create barriers to communication. Common phrases like, “I will do it myself, I cannot wait for IT”, highlight the pressure business users face as they grapple with rapidly changing external environments. SaaS products can provide a lot of potential, but can the risks be managed, and opportunities be created?
Experimentation and iteration have value. Learning is derived through trying something new. Pini Raviv argues that “IT Teams are now productivity enablers”. This is an excellent point, the opportunity hidden within the rise of shadow IT comes from the communication gap. This gap represents the unmet potential currently being filled by SaaS products. Business users have the clearest picture of their own needs and requirements while IT professionals have the knowledge and capabilities to ensure the technology employed is capable, stable, and secure. Eliminating any distrust and friction between IT staff and business users is critical to leveraging the opportunities available from SaaS solutions; while simultaneously ensuring IT infrastructure stays out of the shadows.
Businesses are constantly under pressure to be more responsive, and Enterprise Architecture is one method driving change through better business and IT alignment. The ideas and principles from Agile Software Development enables more responsive organizational processes. In our blog post, “People do not update like Software” we mapped the principles from Agile Software Development to developing people. This time we will redefine Enterprise Architecture using the same approach.
Enterprise Architecture as a practice, has struggled to mature since its creation 30 years ago. Svyatoslav Kotusev, author of “The Practice of Enterprise Architecture: A modern approach to business and IT Alignment”, stated that, “the challenge with Enterprise Architecture is the distinct lack of empirical evidence of successful implementations using established frameworks.” Jason Bloomberg mentions in his article that, “unfortunately, Enterprise Architecture (EA) is often synonymous with the practice of documenting one person’s viewpoint of their company’s IT.” Despite Jason’s article being over 5 years old, we regularly see Enterprise Architects operating in isolation within their organization.
Enterprise Architecture is like pie plate spinning, with each plate representing the organization’s strategy, business processes, IT systems, and people. When managing these elements, we cannot take advantage of conservation of angular momentum, to set up steady states. In today’s business world, steady states are for dinosaurs. Political, economic, social, and technology landscapes are in constant flux; therefore, Architects must keep the plates spinning, yet actively work against the organizations acquired “angular momentum” to drive change. How can one keep the plates spinning, yet guide the organization through change?
Agile Enterprise Architecture
It takes a Village to Architect a Village
Organizations are dynamic multi-dimensional ecosystems. Where Enterprise Architecture fails is that a solution cannot be engineered through documentation. For an organization to be agile, it must work against its own momentum. The responsibilities of Enterprise Architecture should not be on the shoulders of a single individual, but shared by a multi-disciplinary leadership team. If Enterprise Architecture is separated into a specialized role, that separation creates a barrier to implementing change because the other stakeholders in the organization have outsourced their accountability to someone else. If we take a core element of Agile Software Development whereby the client is engaged throughout the development process, we require a governance structure that enforces regular engagement with the stakeholders in the organization. To satisfy this requirement, a team/committee made up of key executives, lead developers, and business managers should handle the organization’s IT. The shared accountability of the group will ensure that Enterprise Architecture practices have better business and IT alignment than an Architect working in isolation.
Differentiate Planning Methodologies
In Enterprise Architecture, current and future state assessments are a frequent practice. While the current state can be defined, the future state is unknowable. It is a good start to redefine current and future “states”, to current and future “focus”. Focus implies a goal or intent to work towards a particular state. While shifting from state to focus could be viewed as a play on semantics, the idea of focus shifts the perceived level of permanence when assigning goals. With new information it is easier to shift focus to a new objective than change the state of a system.
Using the diverse Enterprise Architecture leadership team, individuals within the group will have planning responsibilities that span from the long-term strategic vision to the day to day. Using focus defines the intended state at various levels of corporate planning. If we examine typical corporate planning methods, a common method is the development of strategic planning documents. These documents are invaluable in defining an organization’s vision, operating model, and required competencies. However, to justify the resource investment to develop robust strategic and operational documents, these plans typically cover timeframes between three to five years into the future. With the external environment changing so rapidly, core assumptions of a traditional strategic plan, risk invalidation shortly after implementation. Striking the balance between robust planning and agility is no easy task.
In response, dashboard planning methodologies like the Business Model Canvas have become very popular. Canvas planning tools offer agility and powerful assumption testing frameworks to deal with uncertain future environmental states, the challenge is to organize what to do next? This is where the Agile method can help as it breaks down projects into small pieces that are completed in work sessions (sprints) that run from design to deployment.
Strategic planning by corporate leaders forms a long-term strategic vision (long-term focus), followed by the business model canvas to drive operational planning (medium-term focus) which defines short and medium-term projects through prioritizing assumption testing, and the Agile method managing project workflow (short-term focus).
Less Technology and More People
In our last blog, we made the case that the practice of software development has shifted from scratch, stand alone development to a highly automated process of linking application programming interfaces (APIs). Both the need for bottom up system design and the shelf life of a solution is on the decline. With off the shelf products covering more end to end solutions, the role of Enterprise Architecture is shifting from technical systems design to organizational engagement and change management. The best solution provides zero value if it fails to be embedded into the practices and habits of staff. People do not update like software and a team of diverse stakeholders responsible for Enterprise Architecture will have a vastly superior impact on initiating change than a technical genius working in isolation.
Make It Your Own
Despite the versatility and popularity of the Agile Methodology, it falls into the same trap as the frameworks for Enterprise Architecture because the practice of successfully implementing the ideas never fully represents a true implementation of the method. Organizations are multi-dimensional ecosystems of complex undefinable interactions that cannot be systematically engineered. Successful implementations reference the ideas and principles found in Agile and Enterprise Architecture and through iteration, discover what works for their unique set of environmental variables. At MERAK, over the last year we worked on developing an internal playbook to automate and streamline operational tasks. What we discovered is that the playbook was not a living document, but a state of mind embedded into the culture of our organization. This state of mind has driven an internal practice of collaboration that has organically discovered methods and practices we have used to better ourselves.
“Adapt” has its roots in Latin. Adaptare – “To Fit”: ad- “To” + aptare “Fit”.
To adapt is to make it suitable for a new use or purpose. For an organization to adapt, it must make conditions within the organization suitable for fostering curiosity and learning. Curiosity is a function of leadership and culture, while learning can come in many forms and increasingly certifications are often used to mark milestones of competency.
On May 2nd, MERAK became a Microsoft Silver Partner by fulfilling all the requirements in the competency of Application Development. This marks a major milestone in our roadmap to become extensively certified within the Microsoft platform. Next on our list is Gold in Application Development and Silver in Application Integration, DevOps, and Data Platform.
Since 1994, MERAK has worked with the tools of the day to meet our clients needs. In custom software development the tools change regularly. Today, software applications are governed by sandbox rules: modern applications share everything and must play nice with others.
Connection is key. Software connects humans to humans, humans to data, and data to data; it is very rare for an application to work in complete isolation. It is also rare for an application to be written from scratch. Modern development is all about application programming interfaces (APIs). An API is a set of subroutine definitions, communication protocols, and tools for building software. With APIs, applications can play nice with each other in the software sandbox.
Typically, developers are not judged by their fluency in a single language or application, but on how quickly they can acquire and apply fluency of newly developed APIs. MERAK is adapting its practices and competencies to be successful in a world where organizations have access to powerful platform solutions.
In the past, MERAK would develop customized solutions for a client; however, the maturity of Microsoft’s solution ecosystem allows organizations to do everything within a single platform, replacing many stand-alone solutions. Mastering this technology environment is our way of avoiding becoming a dinosaur.
As these platforms evolve the tools/APIs are new to everyone, including experienced developers. Our certifications give clients the piece of mind that we can help their organization stay technology relevant.
Change is so hard, doing nothing can feel like a perfectly rational decision. Unlike software, people cannot be pushed new instructions to execute (though wouldn’t that be nice?). People do not update like software.
The software development industry is forged in the fires of continuous transformation. The ideas that have allowed software to eat the world, can give us a framework to update people. Experimenting with the idea of “Agile People Development” can give organizations the extra agility that is required to stay technology relevant.
AGILE SOFTWARE DEVELOPMENT
Agile Software Development (when utilizing SCRUM methodology) is an iterative approach providing deliverables to the client in time-boxed phases known as sprints. Agile’s goal is to engage clients continuously ensuring that the defined software requirements more accurately reflect their true needs.1
Software projects can be complicated but feel like a cake walk when faced with the challenges of changing an organization’s culture. It is often better to act than be forced to react, but if change is not in the DNA of your organization how can Agile Software Development principles help?
AGILE PEOPLE DEVELOPMENT
Agile Software Development is an iterative approach; therefore, we need a system that enables iterative experimentation to test ideas and get feedback to build a better understanding of the true path for the organization.
Many of the stages in the Agile People Development model are familiar modes of work; but like life in general, the first step will feel the most painful. Getting started is the admission that what we know right now might not be what is needed to solve tomorrow’s problem. What should be done?
Let’s look at an example at MERAK, in which we had a need to formalize some internal processes, affectionately known as the MERAK playbook. We wanted a structure that exemplified a living document, driven by staff to help automate and streamline operational tasks.
The next step is gathering requirements. Activities may include brainstorming, document analysis, research, focus groups, interviews, workshops, surveys, questionnaires, etc.. The purpose should focus on understanding the environment that contains the problem and generate ideas for experimentation. For the MERAK playbook, we conducted a cultural assessment, held brainstorming sessions, structured interviews, and researched industry practices.
Experimentation is a tricky and difficult step on numerous dimensions. There is a level of ambiguity and risk involved with trying something new. Culturally, many organizations have trouble executing at this stage. The fear of making mistakes, looking incompetent, and possible failure can lead to gridlock because doing little or nothing feels like the safe option. Experimentation requires leadership to empower staff to move outside of their comfort zone and learn to fail with grace. Establishing values of curiosity and humility, while fostering a blameless culture will help focus on objectives instead of assigning blame over inevitable mistakes. At this stage of the MERAK playbook journey we experimented with role plays and internal showcase projects to test various ideas and iterate on learnings. One successful result of this approach was the Stars Bot Staff Appreciation Platform, which can be found in the portfolio on our website.
The growth phase begins when the organization discovers some nugget of truth or insight. It is imperative that this information be shared. Currently, the MERAK playbook project is at this stage, we have two core learnings: 1) focus coordination of projects on a common communication channel and 2) creating a knowledge management tool more effective than Google Search is very hard. With these learnings we have focused iterations on honing our communication governance within Azure DevOps and Microsoft Teams.
Once a practice feels complete, the organization is pulled into the newly developed practice and execution thereafter falls into a well-known domain of incremental improvement. Lastly, feedback and a system for accountability will ensure the organization is in alignment towards its objectives. For MERAK we are in the process of implementing an Objective and Key Results (OKR) system to manage our medium and long-term aspirations. 2
The process is inherently uncomfortable, but the friction of change is the process by which people update. Through adaptation and growth your organization will be well positioned to stay in the game.
With a low bar of entry and yet powerful enough to build a career around. All of us use it, all of us love it, all of us hate it. Excel’s flexibility and richness of features make it the 21st century digital swiss army knife.
It is an addicting feeling crushing a messy Excel problem, who cannot recall the first time they INDEX(MATCH)-ed? The Excel problem solving addiction puts power users on the quest path into Excel wizardry and then face to face with the Excelinators Dilemma.1
WARNING: Magic comes with a price
The first payment is due when the value to innovation S-curve begins to peak, yet many power users meet each new problem with more Excel. The second payment comes a little later when the “incumbent” Excel solution has become so large and complicated that the organization has begun erasing value with the time spent in maintenance and errors.2
There are some warning signs:
Complicated and time consuming process to produce effective decisions
Contains heavy use of macros and VBA script
Only a small number of users understand how it works, or the original author has left the organization
The Excel sheet is amazing but now everyone wants to use it
It is difficult to determine when the spreadsheet has an error, and where it is
It is important to understand the domain competencies of users. Power users are typically professionals that use applications, like Excel, to enhance the value they provide to their employer or clients. A great accountant, financial analyst, or operations manager is defined by the quality of their decisions not the sophistication of their formula nesting and pivot tables.
When has an Excel project used source control, pipelines, boards, backlogs, or quality assurance? These domain practices fall outside the competencies of a typical power user. An organization may lose value when its non-IT professionals are performing roles better suited for software developers or data scientists. Much like when small incumbents disrupt a large organization, to stay technology relevant, there comes a time when new tools and ideas must take over.
Under the right conditions Excel is invaluable, because it is magical. Just remember, extraordinary power comes with a steep price for those that use it irresponsibly.
Innovator’s Dilemma by Clayton Christensen, a classic book that explores how successful, outstanding companies can do everything “right” and yet still lose their market leadership as new, unexpected competitors rise and take over the market ↩
Staying technology relevant is not a one-time task, but a practice requiring humility, experimentation, and collaboration. Numerous management frameworks describe optimizing strategies and processes for changing rules, but technological disruption changes the game itself.
Humility
Humility opens the mind to the possibility that what we know today might not be what is needed to solve tomorrow’s problems. The collective experience or education of staff and leadership does not matter, an organization does not know what it does not know.
Experimentation
By testing ideas through repeated experimentation, successes and failures accumulate to provide valuable learning lessons about your organization’s capabilities and market needs. Additionally, experimentation allows staff and leadership to build effective collaboration processes.
Collaboration
Collaboration is crucial today, as we work in multi-disciplinary teams that coordinate activities both at scale and with precision.
Organizations fail when they rely on what they know to respond to rule changes but do not see it is the game that has changed. Whether your core competency is the development of technology solutions or you use technology as an enabler of your organization’s strategy, staying technology relevant is a core competency that is going to keep you in the game.
For anyone trying to decide on whether to adopt or pursue certifications in PMI’s methodology (PMP/PMBOK) or PRINCE2’s, here is a suggestion: do both! There is some overlap, but both have original ideas and both will add value to your organization.
If you are already familiar with one methodology, and are wondering about the other, perhaps this guide can help get you started.
Both Methodologies outline broad breakdowns of the steps (phases, iterations, call it what you will) of a project. Here is an interpretation of how this aspect of the two methodologies can be cross-referenced:
In addition, both methodologies outline the “how to” aspects of project management. PMI calls this “Knowledge Areas” and PRINCE2 refers to it as “Themes”. The following table depicts how the two methodologies might be cross referenced. Of course, these do not align as closely as the themes/processes, and the table may need adjustments based on the specifics of your organization.
Both methodologies outline all kinds of principles and ideals, however, PRINCE2 lays these principles out in a straightforward manner. These principles capture some of the most important aspects of two excellent project management methodologies.
Here at MERAK systems we did not have a good way to send clients sensitive information safely. This was a problem and was holding MERAK back; there were ways of sending the files however it was long and tedious.
We needed a SFTP (Secure File Transfer Protocol) site to transfer sensitive information in large files to a client safely and protected. I had heard about Pydio from a mentor, who had said it would work well for MERAK and is open source. Looking into this I learned Pydio (formerly ajaXplorer) is an open source alternative to Dropbox or programs alike.
Pydio stands for “Put Your Data In Orbit”. It is a file sharing platform for enterprise, with simple web and mobile apps, hosted securely on a server or cloud. Deciding to go with this file sharing platform, I setup an Ubuntu server to host Pydio. I was relatively new to this type of setup but the instructions were fairly easy to follow and was up and running in a reasonable time.
The layout of Pydio was slick, simple and easy to use. With Pydio we were able to setup accounts for employees. This allowed them to send client’s password protected files.
In simple terms Pydio works like this, a created user sends a minisite to a client’s email. This email comes with a URL (link to the minisite), username, and password (alternatively a user can send the email without login information and contact the client by other means). The client then clicks on the URL; this brings them to our hosted Pydio site. However these sites are restricted and only allow the clients to see files shared to them. Clients can also drag files into the shared minisite to make adjustments, counter offers, share additional files…etc.
Pydio comes with a number of nice features. Some of these features include, Syncing Pydio with our AD accounts. A “watch” feature, which based on a user voluntary opt-in, alerts can send email when the content of a file or folder is either modified or consulted. Numerous plugins to make Pydio look and do what you want it to. Overall Pydio has made things simpler and safer which is exactly what MERAK needed and wanted.
Estimating is one of the most challenging aspects of software development projects. If you work in an organization where management expects estimates that are accurate down to the last cent, even though you have nothing more than a couple pages of high level requirements written before the project even started, then you have likely witnessed the frustration and stress this puts on a project team. This often results in resources who are very resistant to providing estimates, and when they finally do, the estimates are drastically inflated with “buffer” to account for the unforeseen.
The idea of building a buffer into estimates is less than desirable. While it provides the project team a sense of comfort, management does not have an accurate picture of the real cost of the project. With a drastically higher budget, they could also pass on a project they may have otherwise approved. If you feel the need to have some sort of buffer, it is better to build a contingency budget into the project.
The simple way to calculate a contingency budget is to multiply the total project estimate by a factor – let’s say 20%. This is not very accurate, but the advantage of this approach over adding a buffer to individual task estimates is that management sees both the expected cost and the contingency cost.
In the buffer approach, the estimates already have the contingency included. For example, with the contingency approach, management can see a $100,000 project has a contingency of $20,000. With the buffer approach, management will only ever know that the project cost is $120,000, but not necessarily why. You can take the contingency approach one step further by using a sliding scale multiplier based on the complexity of the project. Say, 10% for simple projects, 20% for average projects and 30% for higher complexity projects.
The danger with the contingency budget approach is the team and management may start to assume the project will dip into that contingency budget and everyone automatically adds the extra 20% when reviewing project budgets.
A way to avoid this pitfall is to provide confidence levels in your estimates. This communicates how accurate you believe your estimates are. This approach avoids the “tacking on the contingency” danger, but still conveys the risk of going over, or under, budget.
Confidence levels do not replace contingency budgets, instead they complement them. Contingency budgets play a big part in long-term financial planning for organizations and as a result provide a lot of value. When management is deciding on whether or not to approve a project for commencement, they will make a more informed decision if they have estimate confidence levels.
What is an estimate confidence level? Based on the name, you can take a guess and probably be correct. Simply put, estimate confidence levels are an indication of how confident you and your team are in your estimates.
There are a few ways to go about implementing confidence levels, but first it helps to understand why they are useful. Imagine NASA designing and building Columbia, the first Space Shuttle. Nothing like it had ever been done before. It was ground breaking stuff, cutting edge, the forefront of technology. Imagine those poor engineers sitting in a room and trying to come up with a realistic estimate on how much it would cost to send a spacecraft back-and-forth from earth to space. According to Wikipedia, the figure they gave back in 1983 was $54 million (adjusted for inflation to 2011 dollars). The actual cost per shuttle flight computes to $1.5 billion.
Compare the momentous estimating task those NASA engineers had to that of a home builder estimating the cost of a particular model of home which they have built dozens of times before. It is pretty obvious the home builder would have a higher confidence level in their estimates.
That’s the “why”. Here are a few options on the “how”:
High/Medium/Low: Indicate your project team’s confidence in their estimates by polling them and coming to a consensus.
Calculate a percent confidence: Poll everyone doing their estimates and take an average. (eg, we are 90% confident)
Define categories: We have never done a project like this before, have done this once before, have done this a handful of times, we’ve done this a ton of times already. Each category correlates to your confidence level.
Estimating is far from an exact science, particularly in our business when there are so many unknowns. By implementing a system that not only accounts for those unknowns, but also ensures an accurate picture of the project costs means everyone will be better off over the long term.
If you’re looking for more ideas or advanced techniques, please see the sites below:
When the topic of mobile applications comes up, people immediately think that a native app is the answer. Before we make that assumption, you first have to look at the problem you are trying to solve before proposing a solution.
What is a Hybrid App?
A hybrid application typically uses web technologies like HTML5, CSS and JavaScript in combination with frameworks like Cordova/PhoneGap. Native and web, brought together.
So What’s the Difference?
Hybrid apps typically have a bad reputation for being unresponsive and clunky and most people confuse them with mobile websites. Really, its the best of both worlds by allowing you to leverage your existing web technologies and enhancing them for the platform. The reason you would want to go from the web to hybrid is to access some native features like the accelerometer, local storage or contacts.
Why does anyone build Native?
If you are targeting a single platform, you would be hard pressed to find a good argument not to build native. Some might say that developing native takes longer but if you created a career on developing against a specific platform, chances are you can do it pretty quickly. The time saving typically relates to the multi-platform angle. Also, if you are looking to build a game app, native is probably your way to go.
Do I care if it’s Hybrid or Native?
Nope, most people can’t even tell. Some of the most popular apps our there are native and you don’t even know it (typically people don’t publicize it). When in a meeting a few weeks ago, I had someone ask if the demo they just saw was a Native app and I told them “No” and they were disappointed. If you have to ask me if it is, does it really matter?
