Microsoft architects council March 2008
•Download as PPTX, PDF•
1 like•185 views
Our approach to enterprise architecture at Kiwibank 2008 presented to Microsoft Architects Council sessions in Melbourne, Canberra, Sydney, Wellington, Christchurch, and Auckland.
Recommended
Recommended
More Related Content
Similar to Microsoft architects council March 2008
Similar to Microsoft architects council March 2008 (20)
Recently uploaded
Recently uploaded (20)
Microsoft architects council March 2008
- 1. Dr Bohdan Szymanik http://bohdanszymanik.blogspot.com Enterprise Architecture Manager, Kiwibank
- 2. 2002 Launch 2003-2007 @ Launch 2008 • Project team • Strong growth • Success! • No customers • Acquisitions • Many customers • Guess requirements • Brand developed • Many products • Building market knowledge • Know what customers expect • Not sure what we would become!
- 3. Market Facing Delivery Teams Service Delivery Payments Delivery Infrastructure Delivery Application Delivery Business Delivery
- 4. Banks = Perfect market + $0 transaction cost payment facilitators + complete symmetrically information risk managers => no banks ! Fortunately(!) markets are inefficient: • Transaction cost is significant. • Borrower credit risk is not clear. Ronald Coase „The Nature of the Firm‟, 1937 • Lenders not fully advertised
- 5. Internal marketing Conflicts of interest Problem solving & Design Business casing the platform
- 6. Are you considered Part of value creation? Or a cost centre? Is the EA considered An enabler? Or a constraint? Language “The business must make the decision” versus “This must be a commercial decision”
- 8. “No rational argument will have a rational effect on a man who does not want to adopt a rational attitude.”
- 10. Governance Innovator Application Designer Typical Enterprise Architect!
- 13. Clayton Christensen, 1997 Successful companies rarely stay successful Sustaining innovation treads water Disruptive innovation creates new markets Disruptive innovation forces company change “Marketing and financial managers, because of their managerial and financial incentives, will rarely support a disruptive technology.”
- 15. Digital Equipment Corp MicroVAX II Dell Latitude D830
- 16. ALCo GM - EMD
- 17. “It‟s really hard to design products by focus groups. A lot of times, people don‟t know what they want until you show it to them.” Steve Jobs, Apple
- 18. Avoid projects • How can you define a project when outcome is unknown? • Agree R&D opex up front (20%) Avoid conforming influences • Sell your people and ideas
- 19. How do you make logical architectural decisions? Do you have group think sessions? How do you define your set of choices? Do you place emphasis on authority? Do you need to get it right first time?
- 20. If Complexity = (program states) Complexity = SV , where S = # of states, V = # of variables Complexity (as states) Variables 1 2 Example, 6 states per variable 6 36 3 216 4 1,296 5 7,776 6 46,656 7 279,936 8 1,679,616
- 21. Imagine a 12 variable system 6 states per variable One single system allowing full interaction 2,176,782,336 program states Two separate systems each 6 variables (program states) = 66 + 66 = 46,656 + 46,656 = 93,312 (= 1/23,000th of original)
- 22. Started with discrete apps GUI GUI GUI GUI Logic Logic Logic Logic Data Data Data Data Core Banking Credit Cards Credit Origination CRM
- 24. 2002 Kiwibank launched 2 2003 first web services; Phone banking 4 Partners: 2004 TXT Banking 2005 Back office apps 2006 Mobile banking; Mobile top up; Customer facing tool; International Kiwibank Internal Development Team 14 6 8
- 25. Colonel John Boyd “40 Second Boyd” “Genghis John” Observe Orient Decide Act – and do it faster!
- 26. You want to remove it But only so far… Beware of those proclaiming number 8 wire and KISS One persons complexity is anothers simplicity You can minimise complexity only so far And then you start moving it around
- 30. In order to win, we should operate at a faster tempo or rhythm than our adversaries… or, better yet, get inside [the] adversary's OODA time cycle ... Such activity will make us appear ambiguous (unpredictable) thereby generate confusion and disorder among our adversaries…" John Boyd, "Patterns of Conflict“, http://www.d-n-i.net/boyd/pdf/poc.pdf
- 31. “The Devil's in the Details I really got over the "get into details right away" attitude after I took some drawing classes...If you begin to draw the details right away you can be sure that the drawing is going to suck. In fact, you are completely missing the point. ... Work from large to small. Always.” Patrick Lafleur, Creation Objet Inc. (from Signal vs. Noise)
- 32. Murray Gell-Mann www.youtube.com/watch?v=KXoHXc0ErBI Saturation Incubation Illumination Verification Helmholtz, late 19th century Graham Wallas, 1926 Henri Poincoiré, 1908 Edward de Bono
- 35. Business Metrics Reporting Communications Security Product Engines Workflow Data Services Business Services Decisioning
- 36. Windows OS Data Management Programmable Runtime Workflow + Decisioning Office Worker Interfaces
- 37. 1. 2. 3. 4. 5. Commercial not business Sell Do OODA (quickly) Work on the complexity Give yourself time to think!
Editor's Notes
- Good morning / evening, firstly, thank you to Mark/Nils and Microsoft for giving me the opportunity to come here and present today. I understand I have about 60/40 minutes of presentation time available and I’d like to make sure that there’s ample opportunities for questions and discussion. If you have questions, please feel free to raise them as we go through the presentation. For me, it’s more a sign of success if each slide provokes some open discussion than if I find I’m the only one speaking through to the end.I have tried to include some interesting asides in the presentation, so it won’t just be banking and IT.
- Let’s start by looking at the history of Kiwibank. As a result of deregulation in the NZ banking environment during the 80s and 90s, the NZ banking market fell pray to overseas bankers – mostly from Australia(!) By 2000 it was estimated that in excess of $1.5b was heading out of the country each year in profit toAustralia, but to many people it seemed there was really no clear reason why a local bank shouldn’t successfully compete. In particular, NZ Post, a company worried about falling letter revenue from the introduction of email, had a decade earlier sold off a small postal banking arm and could now see an opportunity to use its extensive network of postal outlets for financial services. This coincided with an election campaign and the issue of a NZ owned bank became an election issue. For NZ Post this was probably beneficial in selling the business case, irrespective, the business case itself was positive. It made sense. I joined the bank project team in May 2001, about a month after business case approval and I’ve stayed with the bank since. It’s important thing to note that at Kiwibank’s launch requirements were speculative, we had no customers, and we weren’t sure what to expect, so we didn’t know quite what to offer.We also had a political environment to contend with that ensured close media attention and demanded launching on time.This drove us towards a package solution that we believed we could get running in time to ensure we could go to market and call ourselves a bank.We competed on value, convenience, Innovation and Kiwi ownershipWe succeeded, and things have changed.We now have many customers – in excess of 600,000 customers, a sizable fraction of the available market.We are a full service retail bank with business banking.And we’ve evolved significantly since launch so let’s look at some of the drivers, the problems, and the solutions we’ve developed.
- We run a simple IT structure at Kiwibank, splitting ourselves mostly on the basis of output but with a specialist group for the arcane area of payments technologies. Business Delivery run our programme office with their main focus being programme governance.My team is the Application Delivery team with a range of development skills and capabilities ranging junior to senior.Across the technical teams I also coordinate an architectural review group made up of the senior architects in Payments, Infrastructure, and Applications. This function is to support governance so it effectively reports into the Project Office.Over the last year we’ve also introduced Customer Delivery teams within each of the market facing business groups. Many of the PMs and BAs that used to reside within Business Delivery have now migrated into specific Customer Delivery teams.
- For those outside the banking sector; the banking business model is very simple.Bank’s are financial mediators. They facilitate payments and manage risk. They exploit the difference in information (sometimes called the asymmetry of information) that exists between parties in a financial transaction and use it to justify their role as the payment mediator. In a perfect market they just wouldn’t exist. Of course, fortunately for banks, markets are imperfect.Borrowers don’t readily release information to lenders.Lenders are unable to fully advertise their presence.Kiwibank’s position in the market is defined by it’s cost to perform financial transactions. I’ve got a picture on the slide of Ronald Coase (Nobel prize 1991 & still alive at 98) because he was the one who first clearly defined the role of companies (and individuals) in a market in an essay titled The Nature of the Firm (1937). (His interest was really around why people organise together into company structures to perform an action rather than operate as individuals in the market, but it’s more broadly applicable to the definition of company boundaries.)For Kiwibank to be a success it must be the lowest cost provider of services to enable transactions between borrowers and lenders.To do this the bank must be the most efficient operator in a market with incomplete information available to it to risk weight a transaction and more broadly a customer.Let’s rephrase: Process efficiency and IP in the use of information are the bank’s critical success factorsSounds a perfect environment for IT!
- For the rest of this presentation I’m going to concentrate on 4 key areas that have taught me a bit more about my role and function.The importance of selling & marketing within your own company.Some of the fundamental conflicts of interest that you need to address.How to approach problem solving & design with an emphasis on complexity management.And finally, how to business case the platform.I’m not going to proclaim myself an expert on any of this but I can share the lessons learnt from my mistakes and also from watching others that have succeeded.
- Architects have a bad rap!Face it, many parts of the organisation think we’re overpaid and don’t deliver. When email fails, when access to the file server slows, or the main corporate applications don’t work correctly it’s our fault. And at times you can’t blame them.A recent Dilbert cartoon had a character wanting to change their job title to include the word ‘architect’ to ‘do less work while allegedly being more valuable’.It’s critically important that you’re recognised as being a contributor to value creation – not a cost.There’s this language that you get throughout organisations ‘The business must make the decision’, ‘The business wants...’, ‘It’s the business that must decide…’.What nonsense!You’re all part of the business. You’re all value contributing!The language just needs to subtly change. People are confusing the term ‘business’ with either the term ‘commercial’ or the term ‘customer’.‘The decision has to be a commercial decision.’, ‘The customer needs this…’, ‘this doesn’t make commercial sense…’ etc.Don’t let anyone pigeonhole you!Your business value comes through as change enablers required to keep your company alive. We’ll cover more of this shortly.
- To sell yourself you also have to sell your ideas.Internal IT departments are not strong on selling. If that’s your strength then you’re likely to be with a vendor.Why should you be selling ideas? Why should you be investing effort in idea generation?The reason is that the shared service lines, and especially IT, are critically important in company evolution. Market facing groups don’t foster innovation because it detrimentally destroys their current power base. Disruptive innovation, which we’ll talk more about later, comes from you in IT. And that’s where salesmanship becomes so important.The selling of disruptive ideas that keep a firm relevant for the long term, is a skill that any firm should value and reward.Vendors actively target and sell to business units in large corporations. IT departments would benefit from operating in the same manner and being seen at the leading edge of idea generation; rather than the group that far too often are seen as policy enforcers that perpetually say no.This begins with socialisation and demonstration to gain attention followed by constant reinforcement.Here’s a quote from Scott Guthrie talking about the development of Microsoft’s successful.net platform."We certainly had to persuade a number of people along the way. One thing wedid early in the project was get running code in prototypes that we could showpeople ... Not only does the prototype prove that it'sreal, but also you just learn a terrific amount by doing it." Scott Guthrie, http://msdn2.microsoft.com/en-us/library/bb266332.aspx
- And if you wanted further argument for why salesmanship is so important, then this is it.No audience in any environment is completely rational and simple rational arguments won’t do. You need something more.There’s a little bit of trivia for those in the Christchurch audience, Karl Popper was a lecturer at Canterbury University for a few years in the 1940s before moving to the UK to teach logic and the scientific method at the London School of Economics.
- Here’s a wonderful endorsement of the role of IT from Kiwibank’s CEO, Sam Knowles, at a recent leadership in banking conference in Sydney in October last year.“The CIO role is moving from support to business leader in the Executive Team”.IT matters!It’s a critical enabler to creating value through innovative application of technology to improve processes and make better use of information.If your IT function reports into the COO or the CFO then the company is in trouble!
- Here’s a many headed Hydra – it’s the typical enterprise architect right!? You’re wearing many hats. The big 3 for me: they’re governance, innovator, and application designer. For you it might be the same or there may be others in there as well. We’ve got room, I count 7 heads on the picture! What’s important here is that these roles don’t actually fit well with one person because of the natural conflicts of interest that exist between them, especially with the governance role.
- You’re asking for trouble if you put the responsibility for innovation into the same person that has the responsibility for architectural guidance, and only slighter lesser trouble with the application designer.I’ve tried to run an Architecture Review Forum for years and it’s never worked well because it was only recently that I figured it should only, absolutely only address one thing: architectural governance, for which the reporting line is our overall programme governance body operating out of the project office. I’m much happier now because I’m no longer confused when I go into the meetings. On top of that I’ve made the chair someone from the project office. I’m a contributor and it feels a far more natural fit.
- What other conflicts of interest exist in a company and affect architecture?How about this one: getting the product right versus getting the right product? An initial solution to addressing this balance is to move some of IT into the market facing business groups to improve the voice of customer advocacy and ensure IT meets business needs. However, two resulting issues have to be addressed: the tendency towards creation of vertical solutions and the tendency to weaken ownership for building solutions right. The most commonly deployed model is the single PM reporting to a steering committee carrying responsibility for managing the overall balance between what a customer wants and doing it right. It’s a lot of responsibility.If you look at specialist software product companies such as the Microsofts of this world then one way to address the conflict of interest is to separate project management from product management. In the Microsoft Solutions Framework you have clearly separated Product Manager and Programme Manager roles sitting at the same level as witnessed by the proliferation of Microsoft product managers and programme managers. Perhaps a model we can learn from in those industries that are not primarily software vendors but which do have substantial software assets created within the company servicing the needs of that company over an extended period of time.We need more dedicated software product teams with long term pride in there work and a good understanding of business requirements across vertical markets.
- Who’s heard of The Innovator’s Dilemma?Clayton Christensen released this book in 1997.It’s got some very simple messages based upon a number of case studies, and in particular the development of disk storage technology. He showed that the incumbents tended to rapidiy lose their market position. They rarely held onto their success because they organised themselves for their existing market environment. These organisational structures and product manufacturing facilities had the effect of creating entrenched power bases that act to keep the status quo. And for good reason, when the market is stable they are maximising revenue for the firm.Unfortunately, the external world keeps changing. Unless a firm can substantially reinvent itself to match these changing externalities a new competitor will arrive and supplant them.Let’s look at a few examples.
- Bucyrus-Erie – I recently saw one of these relics off the side of a road on my way to Palmerston North. They dominated the world of steam bucket shovels from the beginning of the 20th century until the 1960s. Although Caterpillar existed, they were a relative minnow in the digger business.Today it’s Caterpillar, and some notable competitors, that now dominate the market while Bucyrus-Erie only exist in the highly specialised mining market. They never successfully made the transition to hydraulic general purpose diggers, which is functionally what they had provided earlier in the century.
- In the early 90s I used a MicroVax exactly like the one on the left. DEC was a huge company with a huge brand. I distintly remember the marketing material, remember this was pre-Internet. It consisted of monthly magazines with professional production teams and large marketing budgets. At the time I could never imagine that the brand would cease to exist less than 5 years later. They simply never made the transition to operate successfully in the PC/laptop market.First subsumed by Compaq, then by HP. From a multi-billion dollar company brand to nothing.
- And here is an example from the world of locomotives.North American railroads were dominated in the first half of the 20th century by two companies; the larger one being AlCo and the smaller one Baldwin. They produced steam locomotives.In the 1930s GM bought in a business that became the ElectroMotive Division of GM. They did not come from a steam locomotive background. They built up their business with railroads on the basis of cost while AlCo and Baldwin custom produced individual steam locomotives for their clients. Their clients always perceived them as producers of custom, highly priced locomotives. And notice the way one of the diesel-electric units that AlCo did turn out kept the poor visibility of a conventional steam locomotive. From being the dominant producers of rail locomotives in the first half of the 20th century both AlCo and Baldwin had completely disappeared as brands by the end of the 1960s.Now here’s the crucial question. Why is innovation important to you as architects?Because you’re independent of the market facing groups. You’re aligned to the firm, you should be aligned to the CEO. When a widget starts to become irrelevant the CEO is going to want to reinvent the company and he’s going to need you. The organisational structure created to manufacture hundreds and thousands of widgets is not incentivised to change. They can’t change until the widget replacement is developed and new business groups formed to deliver it and maximise the benefit from it. You can imagine how the previous widget hierarchy feel about that.So you’re crucial to the long term commercial success of your company! You’re a fundamental part of the business!
- Now here’s a quote from Steve Jobs.There’s a common statement that I (very) often hear. ‘We must ask our customers what they want.’How can you disrupt the market when your customers are buying on the basis of what they know is available. Your customers aren’t the visionaries. That should be you.Here’s a question for your own companies.Are you leading your customers?Or are you following your customers? (And if you are then who’s leading them?)
- So, how do you provide an environment that is going to support and foster innovation within your company?If you want innovation then you need to avoid projects.Projects are well defined with strong governance. They exist to implement change once change is understood.You need an environment that supports experimentation and demonstration. If your teams don’t have the time to prepare demonstrations of the potential commercial benefits of new enabling technology, then work harder to get it.In our case I keep selling the idea of a 60:20:20 model. 60% CAPX, 20% OPEX support etc, 20% internal learning and development – call it skunkworks. We have a time tracking system and I publish a KPI on our sharepoint site for time spent on R&D time versus project time. Some months it works out, other months it pedal to the metal on the project work. In a recent interview the head of Microsoft Research, Rick Rashid, said that the reason Microsoft has remained successful is because of its ability to change – something directly enabled by Microsoft Research. They have 800 PhDs who are able to publish freely (unlike Google labs). He noted there wasn’t a Microsoft product that didn’t have some MSResearch IP buried inside it.Conforming processes are the enemy of the corporate. Sign off by an ever increasing number of stake holders will only ever ensure increasing dilution to a state of mediocrity. But, since it is impossible to reduce the impact of increasing stakeholder presence the objective has to be to continuously improve the effort allocated to selling and educating to the company. You need to continually socialise and market your ideas.
- There’s really alarmingly little guidance for an architect on how to design. It’s bad for application architects, and if anything, it’s worse for enterprise architects.In preparing for a recent presentation on EA methods I was struck by the fact that each of the major frameworks (Zachman/FEA/Gartner/IAF etc) leave the decision making step subjective and unspecified. There are no repeatable processes; decisions aren’t easily verifiable. You brainstorm, you employ specialists, you run focus groups, you listen to the business, you hold meetings and steering meetings and review meetings. Basically it remains witchdoctory.So what’s wrong with these approaches?All the irrational problems that we humans have with any other decision making.We’re subject to the status quo bias, we don’t like to change unless we have to.The way in which choices are presented can affect our decision, the order in which choices are presented can affect our decision.We’re extremely susceptible to groupthink deference to authority. You don’t get the truth through opinion polls! We prefer human interest, anecdotal stories than analysis through facts. We readily accept obscured and confused definitions of a problem domain. It helps hide the fact we know nothing about it.On the subject of language here’s my pet hate the improper use of the noun architect as a verb.In looking at decision making processes relevant to an EA the most attractive ideas I’ve seen have come from Roger Sessions with his Iterative Partitions approach to reduce complexity. We’ll talk about that shortly. Do we use it at Kiwibank? No. I’d like to say we do but it’s not true. Perhaps the nearest we’ve come to objective decision making has been via the reasonable effort we’ve made at introducing six sigma in the bank. It’s a fancily marketed version of what scientists and engineers do all day. You observe, you come up with a hypothesis, and you make a prediction which you test. A hypothesis can never be proven only found wanting.
- Why is complexity important?Well,let’s do a quick analysis of the complexity of a system following Roger Sessions arguments. Firstly, you need to ask yourself what defines a measure of complexity. Is it numbers of lines of code? Cyclometric complexity perhaps? This measure of complexity was developed by Thomas McCabe in 1976 and it has recently be added into Visual Studio 2008. It gives an estimate of the number of independent paths that can be taken through the code.Sessions takes the count of the number of states a system can be in as the measure of complexity. If you do this for a system such as a group of dice, each with 6 sides having different possible values, then you get a complexity measure which grows with a power law relationship equal to the number of states to the power of the number of variables that can have those states. Such a system can rapidly become complex. But what happens if you change the architecture of the system to separate out the uncontrolled interactions which allow variables to take on states unnecessarily?
- Well, let’s jump to a 12 variable system. Even worse!What we want to do is reduce the level of interaction.If we can stop the interaction then the total number of states drops dramatically.So, imagine splitting the system such that 6 variables were in one; the remaining 6 in the other.Then the total complexity (as a measure of total number of program states) would be dramatically less (in this case 1/23,000th of the original complexity).That’s why componentisation is so important.And that’s why an SOA is so important. It provides us with commonly accepted technologies for breaking complex monolithic systems into autonomous units that we can mix and match to achieve the business processes we’re delivering to our customers.
- We started with a collection of discrete applications but rapidly realised that we were building a multitude of interfaces at different points in each applications stack – GUI, through business logic, through data.We’d started a bank with a clean slate but were rapidly introducing complexity.Of all the interface methods that we’d applied; the most attractive seemed to be the use of web services to create an interface into our externally hosted creditcard system. The obvious choice was to extend the web service interfaces across all of the other systems in the bank.We just needed a driver.A larger existing corporate would have had to embark on an SOA programme, for which the business case is weak; and in many cases the effort would probably fail at high cost, great frustration and significant hair loss.For us, we just needed some new example of functional delivery requiring an interface to the core applications. The first one to come along (after just a few months) was to rebuild our phone banking application on our new VOIP telephony platform. We went to market looking for a VOIP solution but the response that came back from Telecom was, ‘look we can do that but we can deliver your phone banking channel interface as well. It’ll just take us a few months if you can provide a clean interface to the banking functions.’. Perfect! Four months later and we had relaunched phone banking on top of a web service interface to our core banking apps. It just wasn’t very hard. We did it very simply – every call, such as GetCustomer, called a subroutine in our core banking system. Our core banking vendor had made it particularly easy for us because they’d already invested in the creation of an XML message specification for calling functionality in their product. We just mapped our interface specification to their message specification.s
- Kiwibank has moved on.From discrete applications with many point to point interactions we’ve moved to a service oriented architecture. It’s important to note we didn’t set out to create an SOA. We had a problem to solve – how to integrate an external credit card management provider in 2002. We thought of using an HTTP SOAP calling method and after gaining some experience with it, it was obvious that this could be a good way of implementing an interface to our main core banking application for back office systems. We took the opportunity to put a sample interface together before there was any concrete requirement – because it just seemed likely to be needed.A few months later it was.While replacing our telephony environment with a VOIP network our vendor said ‘you know it’d be easy to implement your phone banking on the VOIP switches, all we need is an interface’, and of course, we jumped straight in and produced a web service based interface to our Ultracs core banking environment. I remember our existing phone banking vendor telling me he’d seen banks try this before and invariably they’d still be working on the bugs 18 months later. We delivered from beginning to end in 4 months with 1 Telecom developer, 1 developer from our core banking vendor, 1 bank developer and some time from me. It was easy.There are two important strategies demonstrated here by the bank.Our trialling of an idea over a few spare hours before a real need existed.Our application of internal resources for development only from the service layer up to the customer touch points. We concentrate our efforts on implementing for our customers, not on core product development.
- Our service layer has been our most successful technology enabler. We’ve used it to launch a whole new Windows .net desktop interface for customer and account administration. We used it to (very quickly) launch mobile TXT banking; we’ve used it to launch a full service mobile banking application. With the rapid improvement in underlying services technology we’ve been able to constantly update our own services to deliver in more complex situations. With the introduction of Windows Workflow we created a workflow managed interface into Citibank for the delivery of International payments services. Your interaction via internet banking is fully managed in a Workflow environment. We now have roughly 400 method calls spread across our banking system enabling customer and account creation and modification, and payments.Of course our use of a service layer that is now this rich has also brought with it new challenges. How to keep alive the IP within the development team to ensure we can fully support all the services that are deployed. For this we found ourselves moving to a dedicated services development team – effectively an internal product team.Our infrastructure has grown from a couple of Windows network load balanced servers to many servers with multiple hardware load balancers in a configuration to support offsite DR. When something goes slightly wrong – and of course now and then it does – it’s quite a task now trying to diagnose the cause of the problem and where it lies. We recently sent 2 people to Redmond to take part in a joint design session using System Center to manage alerting and responses. We’ve yet to deploy but it’s an area of focus for the remainder of the year.Our continual focus on growth means we’ve had to face many challenges with adapting our services for an ever greater number of tasks. I see no reason for this to change over the coming years.
- Now the question comes up, if we’re going to start breaking up our monolithic systems and creating our autonomous units delivering basic business capabilities, how do we approach doing it?Do we plan out our program of service interfaces methodically? Or do jump in and do in a series of small iterations making refinements along the way?Roger Sessions suggests we look at John Boyd and his OODA Loop theory for guidance.Visionary behind the F-16, outspoken critic of the US, points toward small iterations done quickly
- What seems complex and without clear intent may in fact just be rapid cycling of ideas and actions, perhaps even done to set you off your guard!
- Of course you still need a good overview…
- Gordian knot – Lorentz versus Einstein – thinking outside the square – Edward de Bono and landscape of ideas + use of heat/noise to enable people to move away from local solutions to reach the right solution.Hermann von Helmholtz was active across philosophy,physiology, physics and chemistry in the 2nd half of the 19th century.Graham Wallas, lecturer at the London School of Economics at the turn of last century wrote ‘The Art of Thought’ in 1926.Of Poincare, it was written by Belliver, that ‘He neglected details and jumped from idea to idea, the facts gathered from each idea would then come together and solve the problem’.And perhaps it’s also about understanding that there is a problem. One of the points Murray Gell-Mann makes is that he was lucky enough to understand a few problems better than his peers which helped him to determine a solution.Bertrand Russell said ‘The greatest challenge to any thinker is stating the problem in a way that will allow a solution’.
- Of course people have been talking about ways to think outside the square for a very long time; here’s Alexander the Great cutting the Gordian knot – a very difficult knot that tethered an ox carriage. The one that could figure out how to untie the knot was prophesied to rule all of asia minor. Alexander cut it with his sword
- And here is a small hand drawing by Guillelmus Ockham from his book Summa Logicae in 1341. He writes “FraterOcchamiste”.Ockham is famous for his statement ‘Numquamponendaestpluralitas sine necessitate’ [Plurality ought never be posited without necessity.] It’s Occam’s Razor – don’t make solutions more complicated than they have to be…
- It’s never going to be easy way to business case the platform.It doesn’t matter what you do you will come under criticism because the sharing across stakeholders is high and the distance of obvious commercial benefit is long.This will always be the hardest sale job you perform.You need to separate out your business projects from your enabling projects.And you critically have to separate the budget.Classic failing – make a business project pay for a piece of infrastructure eg a database server.Automatically this transfers ownership of an infrastructure asset to business groups.This creates a barrier to later reorganisation or consolidation.It’s important to charge based upon a service model.And looking forward you have to ask, how much longer will basic infrastructural services be provided within a company and not managed from large, probably global suppliers.Why is it that we all run multiple, less than perfect implementations of mail servers and file servers. I’m sure we’d get more reliability from a global supply model. Recent efforts by the likes of the Windows Live team and Google point to a future where we buy in basic services from global providers. (Who uses SkyDrive, Office Live Workspaces, Google docs or hosted mail from either Microsoft or Google? Many do and many more will.)
- Microsoft have distinguished themselves with a rapidly evolving product strategy that has seen them build a platform that stretches upwards with ever increasing end usercapability.It’s a model for platform development across infrastructure and applications that many other non-IT sector companies could learn from for their internal systems development.Build up.Re-factor vigorously.Constantly thing through the end to end platform.
- If there is just one thing I want you to take away; it’s to change your language and change that of the people you work with. You’re in the business, you are the business. You make commercial designs, you contribute value.If I was to suggest two other messages, then they would be design the organisation based upon conflicts of interest and avoid the detail.