This post is part of my collaborative research with Shinsei Bank on highly-evolvable enterprise software. It is licensed under the Creative Commons Attribution-ShareAlike 3.0 license. I am indebted to Jay Dvivedi and his team at Shinsei Bank for supporting this research. All errors are my own.
Judging from comments on earlier posts, there seems to be some confusion whether these posts articulate design principles that Shinsei seeks to follow, versus descriptions of how Shinsei’s systems actually work in practice. Jay has mentioned to me on several occasions that he believes current implementations capture only “15%” (I think the number should be understood as an impressionistic estimate rather than a precise value) of the design principles. From studies of specific systems at Shinsei, I’ve observed implementations that adhere to these design principles to greater or lesser degrees, but none that could be characterized as complete, reference implementations.
Thus, the ideas developed here should be understood as a sketch of systems as they might be and are, at least in some cases, in the process of becoming, rather than as descriptive research about existing systems. That said, audited cost estimates suggest that Shinsei may be capable of building systems at a small fraction (perhaps less than one tenth) of the cost of traditional vendors, and I think it’s likely that these architectural principles–even if only partially implemented–contribute to this performance differential.
In conclusion, then, this research falls squarely in the domain of theory building rather than theory testing. Ultimately, the value of such research is perhaps a metaphysical question; I refer skeptics to my defense here.
Hi David, thanks for the clarification as from your blogs I thought that most of the things are implemented. 15% implementation in 10 years time is quite a low success factor. Designing, building, deploying and running technology is a science and scientific principles are clear precise and implementable. As you have embarked on a journey of building / documenting theory I hope it is atleast theory not a fantasy or fiction.
I would like to also highlight that 1/10 as mentioned in your blog is a relative number. there are two aspects to these assertions
1. It could be 1/10 or 100 or 500 which is either 10 or 50
2. 1/10 – depends on what, how, why, and for what. You can spend 1 $ to get a pen and may be 1Mn $ as well.
Doing things cheaper – I can assure you whatever number is taken up someone else can do it in lesser money. You can do a personal exercise to prove this, buy something from the market and ask your friend to get it cheaper he will definitely get it.
Cost of technology – how things are designed in technology constitute only a part of how expensive or cheap technology is there are a large number of other factors which will impact how cheap or expensive the technology is including how cheap or expense it is to maintain.
So you should not only look at design principles, but purchasing including outsourcing, business objective, management of enhancements etc. in case you want to look at it from a wholestic aspect.
Mr. David, could you explain what your reseach is about and what is the methodlogy you have adopted.
Your blogs seem to conflict on one hand you say it is reseach about shinsei and its methods on the other you mention that it is about ideas and not what is implemented in shinsei. Could you clarify what it is about and what is the methodlogy adopted for clarity even if it is about ‘theroy building’.
Takahashi, thanks for your question. I’m sorry if my comments on this topic have been confusing. Let me try to clarify the matter.
Jay and his team at Shinsei have developed a collection of very interesting design rules for enterprise software.
Through interviews and analysis, I’m trying to understand these design rules and, using the design rules as a starting point, construct a coherent architectural theory of how enterprise systems can be made highly evolvable.
Since this is theory building, I will use a mix of methodologies. Initially, I’ll focus on explicating the design rules as Jay and his colleagues have described them to me. As my understanding deepens, I’ll attempt to apply logic and ideas from computer science to identify salient characteristics and possible implications of the design rules. Once I’ve developed a clear conceptual structure (this will probably take another six months or more), I’ll try to do some simple modeling and algorithmic analysis to derive some sharp and testable hypotheses.
From the preceding discussion, it should be clear that the focus of the research is Shinsei’s design rules. Although I believe that these design rules are followed within Shinsei to a substantial degree, at this point I am interested in the functioning of existing systems only to the extent that they help me understand the design rules.
This may seem odd to a practitioner, but my first goal is simply to understand the design rules, not to evaluate the degree of compliance with the rules or even the effectiveness of the rules. Obviously, I believe the rules are interesting and potentially revolutionary–otherwise I wouldn’t bother studying them. But I cannot answer questions about how novel or effective the rules are until I have articulated clearly what the rules are.
David, Thank you for your clarification. Understanding and trying to document design principles is a novel idea. Also i have gone through the blogs and found that most of the items listed have great impact from technology deployment perspective. documenting them could help a large variety of people
All i am wondering is that there is contradiction in what is being stated. For example you mention that “the focus of the research is Shinseki’s design rules” prior to that you mention “current implementations capture only “15%” (I think the number should be understood as an impressionistic estimate rather than a precise value) of the design principles”
If they are shinsei design principle may be they might already be clearly state and documented for staff in shinsei to follow. So maybe they might already be clearly state and documented for staff in shinsei to follow. So maybe it could jump start your research instead of trying to document them again (just a suggestion). Alternatively if they are not implemented or documented how can they be called Shinsei design principles.
Just one more clarification, how many different people are you interviewing and how may levels up or down in the organisation.
Takahashi, there is some documentation, and I have used it where possible to aid my investigation. However, the design rules are not yet fully articulated; many of them are tacit knowledge held by Jay himself. Indeed, this is part of the reason that Shinsei has asked me to undertake the research: they would like to develop a clear and comprehensible articulation of the rules to help embed the knowledge within the organization after Jay’s retirement from the CIO role. One can thus understand the first phase of the research as a kind of knowledge engineering task.
There is nothing contradictory here. Large organizations are complex and have a broad array of systems built by many people over many years, so it is hardly surprising if design rules are not fully implemented. Often systems are developed by other firms, which do not necessarily understand or follow design rules. Moreover, the design rules that I’m describing have been evolving and remain partially tacit. But rules can exist even if they are broken or misunderstood; the rule is a statement of how things should be, not a description of how they are. Indeed, enforcement of rules often requires clarifying, codifying, interpreting, and communicating them.
My interviewees include about five key members of the Business Infrastructure Group, including the current and former CIOs (Jay and Okano-san), the current and former general managers for software, and a business analyst. I’ve also spoken with the former CEO (Yashiro-san) and several people at a firm that develops software for Shinsei.
Mr. David, Thank you for the clarification. It is good that you are helping document the tacit knowledge held by a few people. As this is the objective of this excercise then it is right to interview just a thoes few people.
Hi David, if Jay as you mentioned has retiered from CIO’s role. “Jay Dvivedi and his team at Shinsei Bank”
The above statement is incorrect, so i think you should correct it, because Jay is only advisor and does not have any team is shinsei. i.e. no one actually reports to him organisationally in shinsei. It is not appropriate for you to potray incorrect information.
also as i understand he will not be advisor beyond december so this is all the more incorrect.