Framework-as-a-Service David James Framework-as-a-Service David James

Framework as a Service

Your product vision is only as realizable as the foundation upon which it is built.

In order to realize your product vision over time—with maximum return on investment and minimum disruption to users—it needs to be built on a great foundation.

Your product vision is only as realizable as the foundation upon which it is built.

In order to realize your product vision over time—with maximum return on investment and minimum disruption to users—it needs to be built on a great foundation. The foundation of software products is composed of technology and people. Typically, these are disconnected entities—developers using whatever technology works to get the job done. They do not own the technology, they just grab what they need from GitHub.

We propose that to evolve your product successfully (i.e. to realize your product vision over time) with maximum ROI and minimal disruption, requires three essentials:

  1. developers must have previously and independently created the technology used to build your product,

  2. the technology must be singular and comprehensive (i.e. a single technology with broad applicability vs. many technologies with limited applicability) and,

  3. the developers must be able to evolve the technology safely and efficiently over the life-time of your product.

In summary, the developers must own the technology, it must be comprehensive, and it must evolve with your product. For this we introduce a new offering in the industry: “framework as a service”.

“Framework as a service” is a core partnership of technology and people capable of reliably executing and evolving your product vision, over time.

What is Framework as a service?

“Framework as a service” is a technology offering for product companies and startups. It sits somewhere between “Platform as a service” and “Software as a service”, a specialization of the former and a generalization of the latter. (See this in-depth article for more information, or this definition.) “Framework as a service” provides you with the developers and the framework to create and grow your product, over time. “Framework as a service” is practical and effective in the short-term and maintainable and scalable in the mid- to long-term.

And, the cost is shockingly reasonable. Instead of being locked into seemingly never-ending and costly release horizons, “Framework as a Service” provides the release cycle at a cost you would normally pay for qualified developer(s) plus a very reasonable monthly service fee to maintain the framework. Regardless of the service level you choose, we stand behind our service standards to the point of obsession, guaranteeing that all framework updates are merged cleanly, continuously and safely into your product; while framework improvements and optimizations are rolled out according to your informed choice, or organically, as a natural part of your product’s growth.

That’s the long and the short of “framework as a service”, as offered by C3UI Group. But the story doesn’t end here… the deeper question of why and how remain.

Dependency Hell—Solved

Why does software fail? This is probably something you don’t want to think about right now. But I think you should (think about it). Reading these few words could save you a lot of grief.

You have a vision. It’s probably big, maybe even bigger than you realize at this moment, and will definitely get bigger as your mind expands into it. At first, the realization of this appears to be a “cash problem”, it seems just possible you could buy that vision, make it a reality. But this is not the whole story. One can pay a lot and still have poor execution, frequently without knowing it or being sufficiently able to prevent it. This raises the question: Can software (since we are talking about software here) be written in a way that will succeed? Developers have been struggling to find the answer to this question since the advent of “Turing complete” programs. After decades of evolving the science of software development, they have come to recognize certain practices, conventions and patterns that tend toward success. Let’s zero in on one of those patterns now—managing software dependencies.

First, what is a “software dependency”? Within a software product there often exists many many bits of third-party software that solve specific problems. Technically, these are called “libraries” or “frameworks”. They are also called “dependencies” because the product is dependent on them in order to function. The addition of these dependencies is a sincere attempt to avoid re-inventing the wheel for each problem that is encountered. The re-invention process is time-consuming and frequently less good than the tried-and-true solution. So, developers have a very strong (and often justifiable) habit of bringing in, and using, third-party dependencies to solve specific problems.

This seems like a good thing to do. At least, until it’s not.

At some point (which is actually inevitable for all software products of any scope) there arises a new problem—having too many dependencies. There’s even a name for this in software development: “dependency hell”. It’s the point in the evolution of a software product where there are so many dependencies (3rd party libraries, frameworks, etc) that integrating them correctly, maintaining them as they each upgrade independently, avoiding (the unavoidable) regressions, and keeping the dependencies working together becomes difficult to the point of impossible. When this happens, the velocity (i.e. the rate of adding new features that work toward the realization of the product vision) starts to decrease, and the rate of maintenance/bug resolution increases, until finally the velocity appears to almost stop, and it finally does.

This is failure. This is the end of line. How do you undo potentially tens of thousands of lines of code that intertwine with their dependencies? How can you possibly justify such a cost? Most can’t and don’t.

But, it doesn’t have to be this way.

One Framework to Rule Them All

What if you could avoid the dependency problem (aka “dependency hell”) altogether and keep the velocity high? Proponents of “Agile” attempt to solve the velocity problem but they do not solve the dependency problem, so finally velocity fails. Reality triumphs over idealism. We need a better way, a realistic way. One that both solves the dependency problem and guarantees the highest practical velocity. C3UI Group offers the C3UI Framework “as a service” to be that solution. With C3UI Framework we have one very large, very stable, comprehensive and rigorously maintained framework that absorbs the vast majority of the dependencies of UI development into one framework. With this one framework and one provider, you get:

  1. reliable and rapid development – the developers that use the framework are also it’s creators so they can move fast and move sure,

  2. uninterrupted software evolution – as your software evolves, we evolve the framework with it, in parallel, by pushing the resuable parts of your app into this highly maintained and tested framework

  3. unprecedented integration – as the framework improves, as it becomes more capable and more efficient, so does your software, and

  4. ongoing growth spurts – since the framework is always up-to-date (per #3), we can quickly spin up new product features on a whim with zero waiting time, zero risk

Framework-as-a-service is a new software development model that virtually eliminates “dependency hell” and guarantees the optimum path to the realization of your vision. Try it!

David

Read More
Meta David James Meta David James

Design-minded

C3UI Group seeks, in a small but fervent way, to help reverse an auto-destructive trend in software development by introducing “design-minded” programming, while making the probably controversial assertion that only individuals with strong left/right brain crossover make good computer programmers.

This article was written quite some time ago, but remains a visionary statement as to a perceived problem in software development… and a hopeful solution.

We are a self-propelled company representing the hybrid union of computer programming and functional design. Having extensive experience in both fields leads us to understand the former by means of the latter.

It is said that visual design requires strong “right-brain” ability, whereas programming requires a strong “left-brain” disposition—spacial awareness and linear organization, respectively. (To what degree this dichotomy is maintained by contemporary understanding of the human brain, we leave aside for the sake of simplicity.) Both these dispositions are essential in their respective fields, design and programming. However, in the field of programming, where left-brain ability is the predominant and engendered characteristic of it's practitioners, there has been a massive failure to build software in a way that can be maintained, scaled, re-used and simply understood. This failure is costing millions of dollars (including lost time and frustration) annually to everyone involved in the field of software development.

C3UI Group (self-propelled company) seeks, in a small but fervent way, to help reverse this by introducing “design-minded”​ programming, while making the probably controversial assertion that only individuals with strong left/right brain crossover make good computer programmers.

As the lead and founder of C3UI Group, I am offering myself as such an individual, via manifested code—expressed in over 100,000 lines of original work, as APIs (application user interfaces), as “frameworks”​ that offer to bring the art, beauty and simplicity back to the field of computer programming, in a form that can grow incrementally, like a tree, remain beautiful in function and never weakening.

All programming languages and frameworks, such as the C3UI Framework used by C3UI Group, that have this special “feel”, are “design-minded”, succeed where others fail, are hugely popular & greatly loved and themselves capable of evolving into becoming the essential tools-at-scale, used everywhere.

- David

Read More