oliver.kling

    7 Posts

    When can one say that a certain type of consensus is worth being called a standard? Let us exclude - for the moment; I might come back to this - the question of formality and ownership. So I am not going to discuss if the term standard depends on the body owning or maintaining this or what the difference between a standard and a de facto standard is.

    Let us start looking at a simple example: the size of a sheet of paper. There are DIN and corresponding ISO standards (norms) defining very precisely the size of paper. E.g. in Europe A4 or the US-Letter have a clear defined set of attributes. And importantly one can easily measure if a standard is met... The norm however does not defined the material or structure (including the typical weight attributes). This leads to the situation that a paper A4 might differ quite well from another piece of paper following the same standard. Very often the definition of a standard incorporates some freedom regarding interpretation of certain 'dimensions' (like the weight or material in the paper example). Such freedom should be a wise and deliberate decision of course.

    In IT there are certainly also a lot of standards - even if we leave the physical world with plugs, pins, voltages and the like aside. Just think about proposals of the IETF (the whole RFCs) , W3C-standards, again ISO (e.g. 20022 with recognized importance and acceptance in Financial Services) and the like...
    If you have ever dealt with a standard like WSDL or Web Services you know that there is most often some room for interpretation (like the weight of paper with the A4 example) left to the implementer. Which partially leads to the situation that two standard compliant products are not fitting to each other and have proprietary aspects. Again the possibility of interpretations should be an active design decision and not a mistake of missing precision.
    Though there are on the other hand a certainly a lot of reasons why a total precision (no room for interpretation) is not achievable, desirable or whatsoever. But let me focus now on my basic question:

    Which ratio of precise definition to flexible interpretation (or extension of a standard) is reasonable.

    There is certainly a span of this ratio (the usual answer: it depends...) and it should be clear that a higher approximation to 1 (means no deviation possible) increases out-of-the box matching of different products. But does that mean that a standard defining having a ration of 0.2 (only 20% of a 'domain' is precisely defined the rest is left open) is not worth going for it or does not help?

    Let me transfer this question now to banking IT (the banking specific part)... If we view 'banking IT' as on domain for a standard (which is of course an oversimplification), what would be a meaningful ratio to go for?. I am pretty sure that in many 'domains' (this is quite a tricky word) one will not find much desire from the industry players (banks, vendors, service providers .... except maybe the regulators) to have a totally precise definition at hand. I have discussed this partially in an older Blog Standardization harms my unique selling proposition so the battleground for the question should be prepared.

    In BIAN (the Banking Industry Architecture Network) an association I am engaged and involved in via my day to day business at SAP: we have defined (will define) a set of standard definitions at different levels of detail, which are building up on each other and which gradually increase the precision.

    The 'BIAN high level standard' is the joint understanding on the coarse grained capabilities of a bank (terminology wise I am referring to the definition of capabilities by OASIS: SOA Reference Model). One could call it a domain model from a BIAN perspective we call it the Service Landscape as it is a hierarchical view on banking specific services. (Please check out the blog from David Frankel about the BIAN Service Landscape).
    Wouldn't it be helpful to standardize banking on this abstract level already. Imagine that banks would take the same model (some would say it is a picture only) to discuss the organization or processes of their banks for certain purpose (even if it is 'only' about purchasing decisions or in- and out-sourcing....).

    The next detailed level is a finer description of these capabilities including a clear assignment of identified IT-Services.

    A further level captures the semantic part of the service definition. Including a business description, a clear definition of pre- and postconditions, a high level message structure plus some more details....

    A final level is comparable to a WSDL-type of definition (regarding the precision) but would of course include the agreed and consistently defined semantics of the upper levels as well.

    Would you call all of these levels a standard or in other words are all worth being labeled a standard (depending on the excluded properties - see above -  of course).

    If I look a today's situation in Banks: the existing landscapes are enormously complex and a mix of grown, self developed and bought pieces. That going back to the highest layer a standard would be an increasing benefit for the industry!
    This would of course not remove integration issues completely but it would be a great starting point and I am sure this would proof to save an immense amount of money for integration already and would enable new ideas and business models immediately.

    So I would say that this is worth being called a standard already - knowing that achieving a consensus on this level is a major undertaking already. But it is quite simple if we don't move we will never be there.  

    Comments on my last blog led me back to an older thought I had about managing and implementing architecture. It is the application of "mission type tactics", which comes basically from military leadership practice and partially is and was adopted as a management instrument as well.

    The basic idea of "mission type tactics" is that a person / organisation in a more global position (e.g. higher up in the command hierarchy or having more authority) is managing the according executing parties in his area of control by giving them a clear and understandable order, that contains a concise description of the expected outcome or goal. Instead of prescribing every step to achieve the desired result the order can be "locally" interpreted and the tools and methods used by the executing group are based on their decision as long as the do not neglect the goal. Not sure if this is a great description or definition, nevertheless I hope you get the point.

    Doing this unveils a few interesting aspects in general:

    a) the basic assumption that the local group is able to act according the goal

    b) the empowerment of the local group to take their own decision

    c) the unamendable requirement, that the local group understands the goal

    d) the enforced intelligence of a local group to solve local challenges on their own behalf, which requires insight into the global target or goal.

    In military history there had been some interesting aspects to address some of this points. One approach included the education and training of people one level above their orignal position or level. This basically means that one tries to enforce the look across the fence upfront. One can translate this into architeture management at least partially.

    I would like to start with the tricky part upfront: in military hierarchy is the preveiling structure, that means upper levels command lower levels. This is not quite true for large software systems with respect to architecture. Managing the global picture is a different task than managing a certain component of it - not necessarily a top down thing. In other words in some areas the global architect is responsible in other aspects a local authority is dominating. Enforcing the global requirements and cross cutting concerns is often done via architecture govenernance and central architecture management and design, however many decisions are taken on a local basis and some of these local decisions are feeding back to the global picture.

    Management of the global picture has to be addressed by the guys working on the parts and pieces making up the big picture. A pure upfront architecture design will not work and here (at least I believe) one can incorporate the mission type architecture idea with more emphasis.

    What are the measures one can take for doing so? An interesting one is the education and knowledge (see above). It would be a good idea if the projects working on one piece or part understand the big picture and accept it as a desirable outcome. I would summarize this as insight into the global challenge. From my view point this also addresses the "not invented here syndrom", which basically often leads to rewriting of functionality. It is especially this point that I think we should turn too much more. I changed my definition of architecture by saying that it is to 80% communication of simple goals and to the rest ingenious and original design (obviously a bit exaggerated).

    But there is no end here. We can centrally command to the projects the execution of architecture as well. Which can be addressed to different types of project management. In the classical project charter one has to incorporate the architecture goals as a deliverable and not a side effect and for agile methods like Scrum architecture belongs to the definition of "done".

    The last point sounds like being very obvious but I have to often seen that the overall picture is not mandated. There is no doubt, that there is always a big picture, but without managing it one gets just an arbitrary one - probably not the best one.

    No doubt, there is much content available for active management and design of architecture. In deed there is so much, that one can wonder, why there are so many systems out having a bad architecture. I am sure, that is true for non-software related systems as well - at least partially. Howvever as I am definitely not an expert in other businesses I stay focused on architecture of software systems.

    I would like to refer to IEEE 1471 definition of Architecture: "The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution."

    This definition seems to be wisely written - it contains the structured approach byusing words like "organization" and "design" as well as the emergent character by "embody" and "evolution". This emphasizes - my interpretation - that you actively can drive and design an architecture but get "architecture" as a characterisitic under the hood as well.

    I think there is not much need to delve into the wellunderstood topics of focused architecture design and management as many books, articles and guidelines are available, which are worth reading. I know that agile architecture management is a bit less discussed but still one gets some hits on an interent search. My starting position is different two both in thinking about architecture not actively addressed at all. There is not much thinking necessary - just by writing software one creates something that has architectural flavour. Even if one just has a very simple program consisting of one class (main) one has embodied design - in this case the fact, that it is monolithic. The second class requires thinking in organization and structure and contains many design decisions on top. The more the decision one takes the more architecture a system has. Probably not an architecture providing desired characteristics like loose coupling or maintainablility but some kind of intrinsic architecture.

    Looking for a methapor I stumpled over ants and anthills - while reading in a book about emergent systems. An Anthill has an organization - thus I would say an architecture - that serves the ants quite well (as I assume again). However there is no obvious central builder or architect dictating next moves and building blocks. Any ant working on the ant hill has a build in blue print, structure or even only some basic instructions how to build the ant hill. Every work and contribution is so to say equal to others. Organization emerges via recognizing local needs, structures and the closer environment. If there is e.g. a tunnel in the hill it is likely to persist over some time and the hill is growing because the location where it was build is accepted (even if this is only true in average).

    A stupid thought experiment - far from being realizable - how can we encourage ants to build a better hill (if this is possible at all) - e.g. requiring less ground, material and providing more internal space (very human perception). Building a central plan does not work - because there is no real hierarchy in an ant colony. The only chance is to empower each single ant with a "better" blueprint. Each worker has to understand the improved design and act according to it.

    Maybe you figured out where I am heading to - how can we transport that inside onto large software development projects? Simply stated - everybody working on the big project has to act according the blue print. Obviously this comparision is poor with respect to many aspects but opend up my mind for one point, that I personally underestimated for quite a while. It is the fact, that one needs to address the insight of software project participants much more. Assuming that over better insight the actions are more according the global plan. The only way I know to address this is communication - if I excludes pychological manipulation and related stuff.

    Luckily software projects can have an active and separate design process, which can be managed e.g. via governance of projects and by reviewing designs and the like. And for today my only take away is that we should not forget to address the intrinsic aspect of design and governance is very important but not sufficient.

    Paul mentioned in his blog the different paths taken by different industries. Where some industries followed early the road of industrialization / standardization others (especially FS) took a different approach. The do-nothing approach towards value chain in FS is rather a consequence of th situation FS is currently stuck into.

    I easily can do both - agree and disagree with Paul. Having an engineering background it is rather easy for me to agree that one should not reinvent the wheel. That means it is basically a good idea to copy:

    • an approach
    • a design
    • a methodology and the like

    and adapt it to specific needs. If the application area of a practice is hardly comparable such an approach has obviously severe limitations - in very rough environments wheels might not be the right choice. A good example for me - though generic to IT - is the adaptation of the waterfall model to phased engineering approaches in manufacturing processes to IT development. A phased approach (waterfall model) fits nicely to the production of machines but somewhat limbers in the development of software. A major reason for this - at least partial - mismatch is the fact, that writing code is an inherent design process as well. A lot of new development methods and processes nowadays include "agile" or "iterative" in their name to emphasis on this, which by the way is not a new insight.

    Think about a car manufacturing process where assembly is adapt to the most recent insights on a constant basis - it is rather hard to imagine.

    After having spent some words on a failed copy approach I would like to come to the FS industry again. I agree that it is always more easy to state that a specific thing - in this case the FS industry - is different. I would like to start with the quote of a former CIO of a large bank: "The IT is the bank" - you can hardly say that about a manufacturing company, where IT is very often supporting the core process of production and assembly. Exactly that is happing in banks almost exclusively in and by IT. FS products mostly have one common characteristic - they are very virtual by nature. Which is true for the counterexample as well - Cash. In its most basic idea cash is a virtual product - if we leave out the tangible cash representatives (coins and paper money).

    This fact implies positive and negative consequences - positive because one can generate a very strong business case for IT support in banking, with the negative aspect / consequences of immediately high dependencies of IT and business. It is hard to change production of a bank without an immense IT project. Banking also pays its dues for the early adoption of IT, which is true as of today. Back to the waterfall model - if we take the comparison with car manufacturing again (I know this is overstressed) banks would produce cars, that in principle would be continuously enhanced and changed over time. There would be no completely new model available. Maybe there is no single part in the banking IT left from day 1in today's landscape (my assumption is however different and at least banks often run on technology stacks invented in the earl days of banking IT) but it is largely perceived as being the same enhanced and changed only. All improvements have been done on top of or within an existing landscape; even core banking replacements do not start on a green field - the dependencies are just too high.

    And there is another slight difference with production of physical goods - it is not only the intermingled reality of process, function, organization and IT but also that the data (of eg: customers, contracts, transactions and the like) reside as first class citizens in this landscape. The consequence is that one needs to migrate these inhabitants in a way that business is not affected either. The following comparison is not really meant serious but helps to illustrate this mash up of business and IT. Renovating IT is like changing and rebuilding a car that is driving on the road with the least possible affect to the driver.

    Thus I prefer to compare banking or FS - if necessary at all - to plant engineering and construction or a total different view to urban planning. Plant engineering applies e.g. a lot of standards assuming (just my gut feeling) that the majority of parts is a purchasable standard tool or technology or part (bandwidth ranges from a tube to move liquids to a pump or motor). These standard elements are combined in a specific fashion. It is very likely that two factories producing the same goods do not share the same blueprint and structure of the factory at all. And there is a very basic rule that can be derived from this - it is the fact that the more basic an assembly is the more standard parts can be used and in contrary the more specific the higher the likelihood that a unique machinery or part is used, which is partially true for the manufacturing street in the car industry as well.

    The second one - urban planning - again emphasize the distinction of unique versus standard. A skyline is unique for a city; the infrastructure however is probably made out of the same technical components. An interesting side aspect is the distinction between an urban planner and an architect. The landscape or better the map of the town is made up by the big picture the map itself and what you get as individual components houses, bridges, sky scrapes and the like. It is rather rarely the case, that complete quarters are destroyed and rebuild - typically urban planning works on an emergent basis - with a few rather strictly controlled guidelines and a lot of indirect measures.

    Coming back to the agreement with Paul - the "80:20 rule" to copy from other industries - I have the feeling that banks did one thing sub optimal. The picture of urban planning works again - the central management of the map was not strong enough - i.e urban planning just was not seen or overruled. It was to often sacrificed for the need of single quarters or buildings in the town. Maybe it is also a bit the fallacy of the banking industry to omit renovation and reinvention on the cost of the short term success - probably much more than in other industries. No one in car manufacturing industries would deny the constant need for renovation of production and products - otherwise we still would see some T-models on the street....

    This headline seems to have some truth in it, let me take a look at that a bit closer.

    If everybody offers the same - let's say, the same services - and that is what standardization is all about - there seems almost no possibility to make your own points. That sounds logical and is partially true for sure.

    Looking at this question I see two major dimensions, the question "what is standardized" and the second one "how deeply or detailed are things standardized". If the answer is "everything to 100%" then we safely can make the headline our only and single true statement. But this is very likely not happening and by the way nor desired nor needed.

     

    But then the question is: What will and should be standardized?

    Diving into that question leads a bit away from the unique selling proposition for a moment. So let us pause the first question and look into the dimensions of standardization. I am leaving out everything below the content or application layer, assuming that proper layering with respect to infrastructure provides the freedom to do so and that these rather technical layers have their own challenges - which I will not discuss here.

     

    Let me call the layer in scope the ‘semantic layer'. I see business applications or business components, object and data models, service definitions (one part of it), processes and the like as first class citizens in that layer.

    These elements, view points or dimensions of standardization are not independent from each other - as examples show: A full blown service definition requires an understanding about the business semantic, which can be e.g. expressed in an object- or data model. Another example is the usage and need of business objects and services in an orchestration or choreography that typically constitutes business processes.

    Let me turn the question back to its origination about standardization and let me do two "what ifs" from specific - of course vastly simplified - view points:

     

    Scenario a) - I am a major consumer of services:

    As a consumer of services I am the owner of my own processes and do not need to take care for ‘any' alignment with a provider on process level. I consume services, which are of course well documented and thus I know the outcome of a service call, and compose them into new applications.

    I do not care, if a service call is a single task or action (e.g. a change on a database table) or a trigger to start a complex process of its own -  that is one idea of service orientation. Thus I am fine if the services are standardized - best for me if I can switch providers on the fly. Nice examples are e.g. mash ups.

     

    Scenario b) - I am thinking about a new B2B-collaboration

    Let us assume that this collaboration requires more than a single service call but a more complex interaction. Often multiple messages have to be exchanged in a well defined scenario or process. To be able to do coordinate this message exchange in a live scenario nearly all details have to be specified, the messages and date elements, the process steps and their sequence, the appropriate exception handling and the like.

     

    This to simple scenarios already show, that the overall use case is determinedly influencing what we need to standardized.

     

    Additionally both scenarios show, that the degree of standardization is not immediately predetermined upfront.

    Especially in scenario ‘b' the question is interesting, one could think about a mandatory core standard that can be enhanced by additional elements. The enhancement would give room for bringing in a unique proposition but of course would require additional effort for an actual implementation.

    In scenario ‘a' one can easily use a classical mapping approach in the composition, thus there is no need for a perfect match upfront.

    This leads for me to a very interesting question, where is the optimum of standardization generically or even in specific cases and can we calculate that from a business perspective?

    Oliver Kling

    Cost of Standardization

    Posted by Oliver Kling Mar 10, 2008

    Standardization is not for free – I do not think that anyone is arguing in that direction, therefore I personally consider a cost based view on standardization as very essential.

    Costs are driven by factors like the effort needed to standardize, which could be a bigger environment or the delayed time to market. Of course standardization also provides huge saving potentials for integration costs.

    Looking back to history of standardization I see two things a) the degree of standardization is increasing and b) there is some ‘natural’ trend or tendency that standardization projects and enterprises appear. Here I completely agree with a comment on my last blog – there is some kind of evolution theory that one can apply to the idea of standards.
    And one selection criteria of the standards evolution is cost – ‘standards’ grow partially widely but mainly the ones that have a positive business case are surviving. On the other hand the environment might inhibit some developments e.g. when there is one hurdle that is hard to take. In the case of standardization in banking this is in my opinion the proprietary legacy world of banking IT. The evolution did not force banking IT drastically enough to develop the necessary ‘agility-genes’ – one could survive long enough without them in many areas.
    In specific situations this has of course happened, we know the examples inter bank payments, security orders and some other domains. Once I heard the sentence that the low hanging fruits are already picked the other might not be worth the investment.

    This is the core issue I see for standardization in banking – especially if we think about Outsourcing and Insourcing of core processes or it related entities of a bank. Not having standardized the complex internal banking landscapes slows down the change of the value chain rather heavily. The integration cost of big outsourcing project ruin regularly the business case of the outsourcing project – to be precise I do not talk about outsourcing the complete IT but only parts of it.

    You see I do not argue any more for any of the two extremes – not standardization versus complete standardization – but I have arrived at a major question: What should be standardized? Business Process, the Banking IT landscape or Banking IT services? And how detailed and precise should such a standard be? Should we try to identify hotspots and define these high priority topics down to a level of MDA – a platform specific model that can be used to generate IT-artefacts? Or can we start with a high level picture and e.g. define a common IT component landscape (the ‘boxes’ and some consensus on what they contain)?

    I think we have to do both – evolution has to happen from many directions. We need standards that are implemented to proof their value (justify the business case) and we need an evolution to a common understanding of the big picture.

    And the good thing about evolution is that you do not need to define the target from the beginning. We can start on the big picture and with the details in parallel – an iterative approach to use a term that fits more to modern IT talks.
    We neither solve the problem from one direction only that is clear for me. The path we follow with this iterative approach is however stony regarding the consistency of the results. We pay our due in a tricky and maybe expensive governance process. Which is a good closing remark – because it fits to the topic of today….

    Standardization is no prerequisite for industrialisation

    "Standardization is no prerequisite for industrialisation" this is surely a provocative statement and is definitely as true or false as the opposite: "Industrialisation is only possible if Standards are available". The truth probably lies somewhere in between.

    Using this extreme view points (drawing a black and white picture) helps to contrast and focus on the essential, which we will do in later discussions.

    Let us start with the first statement - assuming there is no standardization, but a need for industrialization. Industrialisation in banking industries simple shall be a reasonable distribution of responsibilities and capabilities across a network of independent companies, which is obviously a very narrow definition (but sufficient for this discussion).
    No available standard means that you have to identify and define a way to interact with your counterparties in the network - every interaction/collaboration is at least somewhat proprietary. Maintaining every interaction/collaboration individually is surely a very cost intensive activity (just think about establishing connections towards a new counterparty). One consequence - there are very likely many others - due to the high "connection"-cost many activities are probably cheaper done within your organisation. Industrialization would happen at a minimum level - one simply can not afford to outsource activities.

    Looking at the second statement - every thing has to be standardized - unveils a different picture. All IT communication is based on a standardized set of properties and thus regulated, by someone who is trusted as a regulator (not limited to geographic boundaries).
    One severe outcome of such a regulation is the limitation of innovation. An entrepreneur optimizing any part of the financial services value chain would find no market due to missing standards for communicating with its target market. At least a severe hurdle would be given by that regulation.
    And by the way how would a cooperation provide an attractive and outstanding offer to a target market if a large portion is prescribed by standarization?

    Of course the above two simplified scenarios are only a thought experiment. We almost immediately see that there is some compromise in the middle of these extremes. It is also a simple fact, that major areas are already standardized in Financial Services (payments, cards, etc.).

    But looking at the complex landscapes within banks and across the banking networks (including other institutions and corporates) it is not clear what should be standardized and what should be left to individualism or proprietary approaches. At least we have identified in these two extreme views some essentials we can discuss in more detail:

    • Costs or the assorted business case are definitely one aspect. Standards need to pay-off in the end.
    • Agility or time to market is a second aspect. Regulation (which - to some extent - is the overhead companion of standardization) and innovation are not best friends.
    • Unique selling proposition. How much room do I need to for my own specific offers, which are distinguishable from other vendors?

    Lets take these essentials and follow up on them in subsequent blogs.