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
Thoughts from a quarter century of working with open technology
There is no rigid, hard and fast definition for what constitutes an open platform or open technology. Rather, arriving at an answer for whether a solution is open versus proprietary (closed) is akin to the adage penned by Supreme Court 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. Rather, 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 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
;)
