In my short but interesting dev live I have experienced a variety of different solutions and approaches to the same problem “how to reinvent the wheel”
Following many meetings I think most of the big companies start to move towards an unified design and look and feel (UX/UI) concept for the whole area of their products.
This article is based on an idea which builds on that vision. It develops the concept of unified UX/UI into an unified Solution stack hub. This unified core solution hub should have all of the controls, concepts, designs, approaches, bundles, packages and the whole software stack and all of the company‘s products will appear as clients to that solution hub. This is how not only all of the applications will use the same design but the whole group of product will have it and also all of the different companies inside the big conglomerate.
Take for example a big company I call it THE COMPANY which incorporated many companies with their different concepts and approaches. THE COMPANY should dedicate one team to create a centralized hub for unified solution stack so that every smaller company incorporated in it could pick ready made solutions for all of their needs which should work nearly out of the box. THE COMPANY and that team should develop ready made solutions for each specific problem of each product. From a business perspective that core team would appear as a company itself I call it THE CORE which is partnering with all of the other companies incorporated under the business umbrella. Those other companies will be like customers to that core solution hub. They will use the solutions from the hub, create requests for new designs, software solutions, organizational concepts, delivery concepts, etc. and will receive support also. THE CORE team should have all of the positions like managers, designers, product owners, developers, QAs, dev-ops, sec-ops etc.
THE CORE team should create all of the components in different layers of the solution stack:
- all concepts for UX/UI with COMPANY stiles and work and feel
- all kind of authentications with COMPANY approach, SSO, etc.
- all of the deployments by the COMPANY release process (B2B, SAAS, etc.),
- new feature and existing software libraries and tools that empower the teams to do their job most efficiently
- manage availability to the whole COMPANY environment
- provide training, support, documentation
- many more
So the main question that each client company dev team should be considering is:
"What is the COMPANY way of doing this?"
If I am a developer in one of the clients for me there should not be a problem of which concept or approach to use. There should be no hesitation and the approach should be already created, tested, implemented, documented and supported. So creating a new product should be just a matter of composing, arranging, stacking and connecting different parts of the already configured solutions.
Maybe at first it sounds too abstract but the idea was to create it once and use it throughout the whole range of products:
"If you have a problem to solve look at the available solution to see if there is already one for you to grab and use"
The structure of THE CORE library should be created to meet many different requirements and to allow the clients (other companies) to spend as little as possible (couple of hours) to start a new project.
Based on my personal experience this approach has many benefits but also some cons.
Pros
- one solution stack:
- researched once
- one architecture
- designed once
- developed once
- tested once
- one built process
- presented once
- configured once
- documented once
- upgraded at once
- patched at once
- learned once
- automated once
- all of the above will save each project the time to “reinvent the wheel”
- all of clients dev teams could be composed of more inexperienced developers because the best practices are already researched and implemented
- all teams will focus on the business logic and business needs rather than components creation
- all teams will have the best of the solution stack available
- fast architectural level decisions because of an already known solutions
- centralized:
- license management
- base security management
- release management
- very agile way of development (no effort for switching or changing some layer of the stack)
- central place for Q&A, learning, feature creation and support
- fixes and patches are applied at once on the global level
- new standards (e.g. GDPR) will be applied at the core level and will be cascaded to all of the products
Cons
- This core team will be a non billable resource
- This core team should be very experienced
- Versioning: every new version will require every team to spend some effort for transition to the new version especially with breaking changes
- Steep learning curve for newly added companies with legacy software that need to be aligned with core standards
- Central application management could lead to a bottle neck for creating new features, fixing bugs and issues, support
- The release process could grow in very complex, staged, gated train with multiple checkpoints
- The speed of core software development is vital for the whole company
- Each team should spent some time to learn (be aware at least) of the new features
This is just a brief architectural concept of the idea but the main point is that this approach will create an opportunity for the COMPANY to grow and develop in unprecedented speed which will create an opportunity to quickly explore new business areas without too much of an effort.
I could say so little of the business point of view but I see many opportunities there.
At the end this approach is not for everybody. THE COMPANY should invest considerable amount of time to measure and calculate all of the pros and cons so that the output to be on the positive side and the benefit to be MUCH greater than the expenses.
Top comments (0)