We’re a bit further down the road of delivering a blockchain solution in the world of project development since my previous article. Time to share some insights about client expectations, project organisation and modelling a business partner ecosystem. To avoid wasting your time with too many abstractions I’ll illustrate some findings with my building construction project.
First some statements. Potential clients have unrealistic expectations of blockchain technology. I spend quite some time trying to explain the real value and the change they face to their business.
Blockchain is no different from other IT heavy projects but there are some governance aspects you should be aware of when trying to develop a business partner ecosystem.
You should take a different mindset when modelling for the Ethereum Virtual Machine. Solidity alert! Data structure boilerplate heading your way. On the other hand, some aspects like the modifier construct are really helpful for abstracting away security, business logic and DAO-like requirements.
This was just a heads-up, let’s dive in.
Client expectations
What’s that new thing again? Yes, I want a blockchain! Why? I don’t know, I heard it’s the next big thing and I really can’t afford missing out now!
Put together a bunch of CEOs, chances are it’s going to be something like this. FoMO is one of the strongest drivers of PoCs in the blockchain space. IT service providers are selling promises of trustless transactions (do we need them?), crypto-signed security (have we solved identity yet?) and frictionless payments (do we have a payment issue?). When in fact they have just found a way to leverage their overpaid backbenchers. No offence, we all need business these times.
If you want to go down blockchain road, you have to think business networks, ecosystems of business partners or at least some process you want to take on with your business partner that you can’t do by yourself. This means reframing your governance by making arrangements across organisational boundaries. A lot harder than just handing out an executive order. So I probe my clients for their willingness to engage their business partners as a conditio sine qua non. I explain this is something they have to do together in order to build trust. Only once you have trust, you can start reducing friction in your mutual business processes by leveraging blockchain technology. Simple statement, hard to accomplish.
For my client this meant implementing a tighter control of the construction phase by using standardised assets, agreed upon by client/demand side actors Developer and Project Manager and supplier side actors Contractor and Subcontractor. They run a blockchain residing multisig contract to approve construction assets having the Project Manager and the Contractor as linking pin in reducing friction and decentralising progress. More on this later.
Key take-away: building trust between Project Developer and Contractor, they should agree upon some sort of standard they can use in both their processes, bypassing the need to abide by single-sided procurement conditions or NDAs.
Project Organisation
To run a blockchain project is in some way governing the developing ecosystem of business partners whom the deliverable is intended for. It starts just like any agile IT project. Lots of iterations making sure the client is getting what he asked for. Instead, we have to take our client’s business partners into account as well. Just like managing a steering committee, a project manager has to manage both paying client and cooperating stakeholder requirements. Business partners have to change their behaviour from defending one’s own interest in a perceived zero sum game towards searching for mutual interest in a shared governance. The agile way requires a product owner representing all parties alike.
As you can imagine, parties involved have to trust you, the project manager, to focus on efforts to enhance shared business processes and not to disclose any sensitive information of one business partner to the other. Fortunately, there is no need for sharing this kind of information, we just have to focus on the contract interfaces and interactions on both sides of the fence. In the construction world, a Contractor is very motivated not to disclose financial arrangements with his Subcontractors. A Project Developer doesn’t care about these arrangements at all, he just want to get the job done against the contract specifications agreed with the Contractor alone. Precisely this contract is worth blockchaining in order to reduce friction in the Developer-Contractor interface. I would not say the interface Contractor-Subcontractor is not interesting, but in this case it’s not the focus of the project from a paying client’s perspective, our Developer. Neither would I argue that it’s all in the interest of the paying client. A Contractor has an incentive too when checked tasks are paid immediately, so he can pay his Subcontractors swiftly, reducing risk and enhancing quality in the delivery phase.
The point is, your project organisation could be hung up on some agile method, but you have to focus on the interfaces and paper based contract arrangements of parties involved and beware of getting too mixed up in requirements analyses and backlogs of one particular business partner, even if it’s the paying client. This is not in the interest of developing the ecosystem, which should be a key success factor in your blockchain project.
Modelling the blockchain
Mostly having a background in IT strategy consultancy, I experienced quite a steep learning curve wrestling the EVM and Solidity language. Some googling reassured me I was not alone. I learned that even senior developers had trouble demystifying the constraints around given data structures. It was only after I read an excellent Solidity tutorial at Monax I got to appreciate the way smart contracts were supposed to be designed.
To begin with, you really have to start thinking in contracts everywhere. Forget about objects, entities or relations, or at least treat them as mere derivatives of contract requirements. Remember, we are focusing on modernising the legacy of paper based contract agreements between parties, an art called legal engineering. These agreements should be a baseline for your smart contract development work. Once you get a grip, you’ll learn to understand that contract-oriented design gives you a lot of flexibility at the execution level.
Activity in any organisation can be modeled as Tasks, distributed to a hierarchy of managers, teamleaders, workforce (people actually producing something) and yes, project managers as well. Let’s model them as Stakeholders with various degrees of authority and span of control. As project managers we like to organise our project as Workpackages in a work breakdown structure as our span of control. So we model Tasks assigned to Stakeholders organised in Workpackages. This is our basic setup, familiar to many project structures. Traditionally at the IT level we model these in an entity relationship diagram. Hold on, we are going to do this in a slightly different way now.
If you start thinking contracts everywhere, you have to consider the parties involved as the main actors of contracts. Every Stakeholder has a contract with an other, or in normal speak you’d say: We agree I promise to deliver you X as a product of task Y you have given me. So first, we focus on one type of contract and design this according to any kind of business arrangement this contract type could have when agreements are known up front, or in the future by asking what kind of flexibility of contract terms is required when circumstances change.
Let’s take the construction project again. A Workpackage type smart contract has three Stakeholders: the Developer — in Prince2 terms Executive Sponsor, the Project Manager and the Contractor or Senior Supplier. We could have justified a Senior User as well, representing the organisation actually buying or renting the building, but to keep things simple we drop this role – for now. These stakeholders sign off in a reverse cascading style: first, the Contractor marks the Workpackage with all underlying Tasks as done, then the Project Manager, checking the work against specifications and finally the Developer, relying on the verdict of his Project Manager after asking some harmless looking but painfully spot-on questions. This is all very straightforward in the EVM using a standard multisig type contract as a helper to the Workpackage contract. However, the contract-stakeholder relation opens up more opportunities to lock things down in this growing ecosystem.
Suppose you as a Contractor want to shield something for competitive reasons, like tasks being carried out by various Subcontractors, whose individual task budgets you don’t want to disclose. You’ll model a distinct Task contract to have two Stakeholders; you, the Contractor and the Subcontractor delivering the product of the task. When you have multiple subcontractors working on a task, you could split this task up in subtasks, each with their own Task contract. This way, agreements between parties are locked down to a one-on-one relationship, simplifying issue resolution when things get messy.
Solidity leverage
I already mentioned the quirks of Solidity, the limited support for data structure handling gave me headaches. However, there are some things I really learned to appreciate. For instance, I make heavy use of the factory pattern (contracts instantiating other contracts) to transfer and inherit ownership of Stakeholders in order to secure transactions against these contracts. Furthermore, the modifier construct gives you a nice handle on abstracting away permissions on transactions. You’ll find lots of tutorials explaining how to restrict access to certain transactions using this construct. It gives you a lot of flexibility implementing your own security rules, by isolating more advanced business logic into separate functions or contracts and using them in the context of the transaction at hand.
As you can see there’s a lot to be learned in modelling a blockchain application. Governance of the developing ecosystem, thinking in contracts, assigning tasks and stakeholders and locking down transactions via Solidity language constructs. I barely scratched the surface, but I hope you’ve got an impression of how to go about. Next post I’ll share the results, when I put this work into practice and collect some ecosystem feedback. Stay tuned…