Some History
I am getting started on a new project. But first, a little history to put it in context.
I have been working in Silicon Valley developing software for over thirty years. I worked at large, medium and startup companies. I developed software for defense, entertainment, social networking, human resources, supply chain, medical, dev-ops and legal applications. I have performed in various roles including an individual contributor, team lead, manager, and software architect.
1980s
Early on in my career, I became convinced that there were faster ways to develop software than the way it is typically done. I set a goal to become a software architect and began learning and thinking about ways to develop software quickly. The conferences I attended in the late 1980s introduced the term “visual programming” and “mega programming” but focused on software design tools at too low of a level (e.g. class diagrams, sequence diagrams) to be practical in creating entire distributed software systems quickly. While the industry focus on design tooling did eventually consolidate into the UML standard for modeling software (where the U stands for “unified”), the tools were complex and did not become widely adopted on actual projects.
1990s
In the early 1990s I ran a small DARPA research project to investigate and promote software reuse using Distributed Objects and CORBA. While the thinking behind CORBA was broader (reusable distributed objects instead of just programming-level classes), the technology was complex, and even though I managed to implement a couple of projects using this tech in that decade, the technology did not catch on. I started programming in Java in the late part of the decade and found it to be a good programming language for back-end services.
2000s
Then in the 2000s as the world moved away from CORBA (and its Microsoft-based competitor DCOM), I learned how to create distributed applications using the J2EE standards. This standard promoted the organization of distributed systems into front, mid, and back tiers. The front tier focused on processing web-based requires, the mid tier focused on implementing business logic, and the back tier focused on storing and retrieving persistent data. While this separation of functionality is a good practice, the industry recognized the value primarily in the front tier part of that technology (Servlets) while deeming the other parts too heavy.
2010s
In the 2010s I saw the transition away from J2EE to Spring. The Spring framework and technologies leveraged the front part of J2EE (Servlets) as one type of component (REST Controller) and provided a lighter weight and better performing framework with a flexible set of back-end components that supported what some people called a Service Oriented Architecture. The Spring technologies continued to evolve and gained incredible industry adoption. During this period, it became easier to deploy software into data centers due to technology that virtualized computing resources (servers, persistent storage, networks). Towards the end of this decade, the main cloud providers (e.g. Amazon, Google, Microsoft) started aligning on Kubernetes to provide a common virtual representation of the cloud-hosted computing resources and services. I led a small team to build and deploy distributed software into Amazon’s cloud (AWS) using Spring Boot and Kubernetes. I learned a lot about the cloud-hosted operations side of distributed software.
Realizations
Acting in the role of a software architect, I realized that many of the application services I designed and built for my employers required a similar set of services. These services provided the functionality to meet requirements in the area of security, account management, content management, social networking (e.g. friends/followers), gamification (e.g. experience points, levels, feature unlocks), monitoring and business analytics. I had opportunities on a couple projects to experiment with ways to implement user interfaces based on building blocks that could be configured from configuration data. This provides a mechanism for tools to produce the configuration to customize the user interface without changing code. I found the same technique works for customizing the behavior of the back-end services (e.g. rules for gamification, custom data for user profiles, definitions for state transition tables and process workflows).
As you can see, much of my focus was technical. I did not realize until the mid-point in my career how important the software development process is for developing quality software rapidly. I participated in process improvement activities for a few employers and gained a great appreciation for process in general and the software development process specifically. I learned the Agile Scrum process on one project and became a believer in its power, not only to develop quality software quickly, but to be able to predict somewhat accurately how long it will take the team to develop something new. The Agile Scrum process provides a clear identification of roles for team members: the Product Owner defines and communicates the product requirements, the Scrum Master facilitates the process, and the other team members build the software according to the process and requirements. This process defines a basic structure and metrics, while allowing the team to be self-directing to realize the team objectives in the most effective way.
Current Plans
With this experience over a long career, I am now able to synthesize what I have learned about technology and process to arrive at an approach to develop quickly mobile and web-based applications with a cloud-hosted back-end with collaboration among a team that includes product managers, product designers, software managers, software architects, software developers, quality assurance engineers, operations managers, customer support providers, marketing managers, and senior managers and executives. The focus on process provides a means to automate many of the collaborative processes required to produce mobile and web applications and the supporting back-end application services.
I am now getting started on my own application and application service. My initial focus is on the automation of processes that will allow me to develop a hosted service very efficiently with a very small crew (myself initially) called the Worth Enterprises Platform (WEP). The purpose of the Worth Enterprises Platform is to enable an entrepreneur with an idea for a mobile or web app to:
- Sign up as a Product Owner
- Build a team from among the entrepreneur’s employees and Worth Enterprises affiliates including a Software Architect
- Specify product requirements and acceptance criteria for the app
- Work with the Software Architect to identify which preexisting components satisfy app requirements (e.g. security, account management, content management, social network management, gamification, monitoring, analytics, etc.) and which custom components need to be built
- Prioritize the requirements and begin the Agile Sprints to incrementally develop the app according to the requirements and tests that satisfy the acceptance criteria
- Design and build the app user interface
- Build and deploy cloud-hosted software and the mobile app into a test and integration environment
- Release cloud-hosted software into production and mobile apps into the app stores
The Worth Enterprises Platform allows the entrepreneur and team members to collaborate together as they quickly identify preexisting components, customize them for the app, and incrementally deploy, test and release a basic app backed by cloud-hosted services. The entrepreneur brings their idea, any initial team members, and leverages the Worth Enterprises Platform and affiliates to provide the rest including the people with the skills missing from the entrepreneur’s initial team. The entrepreneur has a basic app ready on the first week and begins the incremental evolution of the app with the team according to the Agile Scrum process across as many Sprints as needed to get the app to its initial launch and beyond.
The Worth Enterprises Platform is expected to evolve over time. My initial goal is to get it to the point where I can provide a good demo to an entrepreneur where we can sit together (or perhaps over Zoom) and perform the initial steps to produce a basic app with some simple customization and then let the entrepreneur try out the app. At that point I will be looking for an entrepreneur to work as a partner on their app that leverages the platform in its initial state to get it to the point where it supports a real app. I will also work on my own commercial app that promotes financial wellness. I plan to post technical articles on my progress as I create the various aspects of the platform.