There is no rigid, hard and fast definition for what constitutes an open platform. Rather, arriving at an answer for whether a solution is open versus proprietary/closed is somewhat akin to the adage penned by SCOTUS Justice Potter Stewart when remarking as to what constitutes pornography — "[You] know it when [you] see it”.
The same is true here. "Openness" is not a binary determination; it's found along a continuum. The way we think about it is the more open the approach, the more it incorporates amounts of the following six elements:
Open Standards: Technology standards that are publicly available and have associated use rights. The IETF’s SMTP and TCP/IP are examples of global open standards. In most cases open standards are much narrower in scope/impact though no less important.
Open Source Software: This is software that falls under an OSI license and is generally free, always modifiable at the source code level, and can be broadly re-distributed. Linux is perhaps the poster child for such products.
Open Code Software: This is a less prescribed class of software. It’s characterized as free or inexpensive and modifiable at the source code level and redistributable under agreed upon parameters.
Open Programming Languages: The popular PHP and Python languages are entirely open source while Java, one of the world's most influential programming languages, is mostly open source. As contrast, a language like Salesforce’s Apex is proprietary.
Open APIs: Often referred to as public APIs, these are publicly available application programming interfaces that provide developers with programmatic access to proprietary software applications or web services.
“Open-Shoring”: This is a term we use internally. It's relevant because the cost, availability and quality of technology talent varies greatly across the globe. Open-Shoring (also referred to as "Right-Shoring") balances the use of domestic/onshore resources with offshore assets.
View Full Post and Comments
When making important capital or strategic decisions any manager worth their salt immediately tries to get a handle on the fundamental tradeoffs presented by the various options. Discipline of this nature should be applied to technology investment decisions. But adding to their challenge is their normally complex and even iterative nature, leading to a process that generally looks as much like art as it does science. For example, grappling with questions like “What happens to our positioning vis a vis competitors if we build X, versus Y, versus nothing?” can lead to paralysis. With the exception of large enterprises that have analysts aplenty, answers are generally incomplete at best or inactionable at worst.
We coach organizations that while they must struggle with those types of questions, in parallel and to keep the organization moving forward, to consider as a predicate that something will be done. This simple technique keeps the strategic dimension on the table while making tactical analysis much more straight-forward and actionable. The decision becomes how and what. Less why.
Below is an outline pulled together for a client and used to faciliate just such a discussion. It identifies, at a very high level, the pro's and con's of using open components like Magenta and Concursive versus a leading proprietary technology like Salesforce.com to implement a customer facing solution.
The table shouldn't be interpretted to suggest that Open is the best approach. It is in some cases, not in others. “Best” depends upon a thorough consideration of the company’s unique circumstances and how management weighs the costs, advantages and different risks at play.
View Full Post and Comments
The size of the organization in which a solution is being considered is usually a key determinant of fit. Large enterprises, highly invested in a single or few platforms like SAP or Oracle, generally apply open strategies to narrower areas within their development roadmaps. Which is how Linux penetrated the enterprise; it was first used in projects deemed less than mission critical and once found to be robust, safe and cost-effective spread more broadly.
For the vast range of smaller and mid-sized organizations, and specifically with respect to Concursive technologies, open strategies are most applicable where some combination of the following conditions apply:
Uncertainty: The organization faces significant growth or change yet the particulars and paths forward are uncertain. Thus, the need to retain flexibility and maneuverability are high.
Control: A high degree of control of the technical environment is desirable so as to mitigate the risk of being held hostage by a proprietary vendor or non-standard technology in a particularly important area. Most organizations don't want to deal at the source code level; but it's a valuable insurance policy and back door knowing that you can.
Legacy systems: The business aims to get more out of its legacy data, administrative and operational environments as jettisoning them isn't an option.
Nimbleness: The business or organization is moving fast and processes, systems and tactics are being developed almost on the fly.
Must move: The organization’s leadership knows that sitting still isn’t the answer, but it lacks clarity on a range of strategic issues and is (rightly) hesitant to bet the ranch on a single technology approach or vendor.
Collaboration: Connecting people, information, best practices and implementing team-based strategies are specific, desired outcomes.
View Full Post and Comments
;)
;)
;)
