Practicing our Principals

Principles and theories are useful to the extent that their practice accomplishes a result.

This is how we apply our theory of design to the real challenges of cloud computing.

Design

The design process for application systems is well documented and understood.  Less defined are processes used to procure, construct, and deploy systems.  When process is ill-defined, procedures to make system changes and address outages are often missing.  Then, problem analysis is only possible after a lengthy rediscovery of the construction of the existing system.  That discovery process is possible, if inefficient, if the expertise that built the system is in-house or readily available.   Often, in small enterprises, "production" systems were implemented by transient vendors who are no longer available to diagnose system failures.  The consequences can be dire for small businesses. 

Every useful system must meet both functional and nonfunctional requirements.  Basically, the functional requirements define what the system should do.  The non-functional requirements describe what the system should not do.  Examples of non-functional requirements are performance (don't be slow), security (don't let the data be stolen), reliability (don't allow the system to break) and maintainability (don't let it be hard to fix or upgrade).

Good design, applied to business processes as well as system functionality, addresses these challenges.

Scale and Complexity

Complexity is our biggest challenge.  Small businesses need to take advantage of inexpensive cloud services.  Implementing any single service is simple.  Complexity increases geometrically as organizations attempt to make the individual services work together.  Single Sign On (also called identity management) is one example.  The picture gets much more complicated when it becomes apparent that a great deal of data is common to multiple applications.  The business must either maintain it in multiple locations or find a way to integrate the systems.

The number of skills needed to support even modest environments is expanding rapidly.  A simple project could require an integration programmer, database administrator, VM Administrator, Identity Management Administrator, Information Security Officer - to name a few.  Large companies can retain this diverse talent pool.  Small and medium sized companies cannot.

Organization and Process Design

The design principles of modularization (reusability) and encapsulation are "pattern integrities".  By designing the software acquisition and implementation processes, we ensure that essential non-functional requirements are included.  Often those requirements are encapsulated in well-defined service requests that can be applied repeatedly across multiple projects.  The Service Requests define the functionality required, the documentation needed, and the means to verify that the requirements are met.

The "modularization" of requirements makes it possible to assign distinct project tasks to domain experts.  The experts need to be engaged just long enough to complete their assignments.  Clear process, configuration and deployment instructions defined in the Service Request, make it possible for administrators to implement, monitor and troubleshoot components introduced into the environment.

There Will Always Be Operations

The simplicity and reliability of some on-premises servers suggests that the need for operations is diminishing.  You have the Admin install the software and then it runs.  That worked OK, because the servers were underutilized.  However, as the environments grow, admins are spending much of their time applying patches and upgrades.  Cloud service costs are attractive because the cloud makes optimum use of the hardware and increases the efficiency of admins.  As a consequence, application systems have less excess capacity to consume with inefficiencies or uneven workloads.

CSDI partners with competent Managed Service Providers (MSPs) to ensure applications are monitored and outages are quickly addressed.  But how are they going to understand your complex systems?

Design and Operations

Operability is an essential non-functional design requirement.  Documentation of system components, deployment and configuration instructions, and monitoring "instrumentation" is required in all of our projects.  Modularized tasks reduce the cost of the documentation and standardize task deliverables.

Just as encapsulation keeps system complexity out of the view of end users, modularization of project tasks, especially the non-functional requirements, allows MSPs to support unfamiliar systems.  Domain experts may still be needed to address future problems.  With modularized tasks, isolation of the problem is simplified and it is immediately apparent which provider is responsible for support.

Designing Out Risk

Information system environments are becoming more complex.  The number of subject matter experts need to design and implement environments is increasing rapidly.  Small organization are impacted by this burden disproportionately.

CSDI engineered processes that mitigate the risk in two ways:  

• By modularizing and standardizing our project deliverables, administrators do not need to be experts in new systems to support them.
• As important, by modularizing project tasks, experts can be engaged from the pool.  There is less requirement for overall system knowledge.  Individual domain experts can make their contribution and are not required for implementation or routine support. 

Dependence on sole-source technical providers is a significant risk to many companies. 

CSDI endeavors to engineer these risks out of our projects.