Architecture options for rented office spaces
Next: Automotive Industry Structure (new topic)
See Also (added later): Vision for Indoor Structure in the Office of the Future
In the previous for parts of the segment of construction we have more or less focused on residential buildings or models how construction industry itself will (can) change.
There are however big differences between residential and office buildings. The biggest ones being that one organisation is responsible for rented office spaces, services like networks provided by the owners and also the buildings tend to have much deeper building frame.
To end this partial look at construction, a few ideas how a real-estate owner might look at the general software architecture of buildings. The options here are very general and tend to apply to any complex environment. This part is heavily influenced by work done by redi.city team. (See more at: https://www.redi.city/en/home#arbete, the IoT document in particular, that is in Swedish)
So here it goes
Stovepipes du jour
Today architectures in complex sites like office buildings follow very often a stovepipe model. Each supplier provides their own fully integrated end-to-end solution and these co-reside. Each function as it is it the only thing in the world more or less. Some APIs on the cloud are typically available for 3rd parties but they are generally implemented as an afterthought and limit access to data and functions based on the vendors sole consideration.
For the vendor this is often the only model to function:
There are no generally accepted standards in most domains to adhere to
Existing standards are results of the consortia members and may omit important aspects for the vendor.
Small vendors feel they lack influence on standards bodies and often do not have financial or intellectual means to send participants
Standards are not written with clarity of expression in mind. This passive aggressive model protects job security for people and companies involved in standardization
And it has benefits for the vendor
This is a modular solution allowing to sell the product across many verticals (increase revenue)
Manufacturer can take in customer requests and implement then fast when needed (flexibility)
This state of affair however has negative consequences for customers
It creates vendor lock-in
Any functionality that touches multiple silos requires expensive integrations.
Integrations need upgrades whenever underlying systems change
Features like predictive care either are impossible or expensive to implement
Result is a system that costs more and has limited functionalities
One system to rule them all
A simple remedy around this is an All-in-One platform. This is what IoT platform (and cloud!) vendors have been selling with mixed success for years.
If the vendor has good interface libraries, the costs may be acceptable. But often this results in very expensive integration projects. The reason for costs is that most vendors do not document their systems for customers very well and inhouse systems tend to have documentations that are so old and out of data that they are more harmful than anything else.
For customers the benefits are that it implements the vision of integrating everything together and providing access to data and functionalities. System integrators can deliver practically all customer needs. This helps create new use services for customers, lowers costs in maintenance and faster recovery from incidents.
The negative aspects are also significant
Total lock in to vendor
Every vendor has their own APIs so application vendors either have to limit their offering to a single platform vendor or incur significant costs in integrating their systems to several.
This industry structure acts itself as a significant barrier for the development of the whole vertical. There are less packaged applications and they are more expensive
Open (source) platforms
Third alternative is a horizontal open platform. This can come in two fashions:
Open-sourced platform developed by an industry consortium offering standardized north-bound interfaces for applications
Or an extension of this that starts with an API gateway on top of stovepipe solutions and offers extensibility via an open platform.
The openness brings significant benefits
Vendor lock in is removed
Any customer can develop new features and functionalities and propose them to be included in the code base
However, there are aspects to consider
Developing an open platform in a significant investment requiring skills and investment from participants
Disputes as to the direction of the platform will arise and a good guardian or resolution mechanism is needed
Device vendors may have to re-implement their current stove pipe architectures using this platform and may fear lack of flexibility and ability to differentiate
A second alternative is a mediation platform on top of existing stove-pipe solutions (no image). A consortium is formed that defines what capabilities and data are needed in future for existing and new use cases. The core idea is to focus on the application developer interface so that creating additional value is as easy and cheap as possible for software vendors.
Underlying platform starts as a relatively modest integration bus or API gateway utilizing the interfaces of underlying systems.
This has benefits
Much faster and cheaper to implement than full open-sourced platform
Focuses on developer experience that is critical in attracting 3rd parties to form a real ecosystem
Existing solution vendors retain their freedom
Can be developed in a piecemeal fashion – one area at a time.
The light weight mediation approach lends itself to extension quite well. Instead of fetching data from the underlying stove-pipe solution, it is possible to add interface libraries directly to the mediation layer. This way the mediation layer can start replacing element type by element type the underlying vendor solutions. Both will exist, vendors do their own thing and the generic platform does direct integration. The different to previous approach is that the investment is spread over many years, based on actual need and even new stove-pipe solutions can be brought in fast and cost efficiently. It is a complementary-competitive architecture to underlying vendor solutions rather than one that tries to replace everything.
Ideally the vendors do the integration to the platform. This can be enabled defining and publishing a south-bound interface specification. Add developer support person(s), and you have the minimum what it takes to attract device vendors to write the adapter modules themselves. Assuming your platform offers enough business volume to them.
There is one more post to come on construction, its on how office building owners could meet the demand of the future from a slightly different perspective.
See Also: Vision for Indoor Structure in the Office of the Future