Blogs
Highlights
Categories
Tags
AI Alignment Apple application management apps Atos Themes bionic computing Business Transformation Changing Customer Cloud cloud computing Collaboration Connected World Current Affairs data downturn Education enterprise architecture Facebook Financial generation y Google ideas information security Innovation Java Knowledge and Craftmanship Linux London2012 media Microsoft mobile New ways of working open innovation open source Oracle Practical recession Research SaaS Security semantic web social media Social networking The Future! Transformation Twitter virtualisation web Working in IT
What has the enterprise architect ever done for us?
November 24th, 2010 John Schlesinger Tags: enterprise architect, enterprise architecture, Working in IT
Posted in CIO Agenda, Data Science, Technology |
A colleague recently had a problem explaining to the CEO of a UK listed company what Enterprise Architecture is for, other than burning a bit of the bottom line and generating impenetrable PowerPoint presentations. So we brainstormed how we might do better next time.
The first problem is that most CEOs don’t actually know what an enterprise application is. I had this problem at IBM in the late 80s. The IBM executives only ever interacted, using their green screens, with personal productivity and communication applications. They thought that was what computers were about. It led to the announcement (September 1987, a date scorched into my brain) of System Application Architecture, IBM’s attempt to unify computing across all its product ranges. This was an announcement in which CICS and IMS, which between them supported 80% of IBM’s business, were completely ignored. SAA eventually crashed and burned and directly led to IBM making the then largest loss in corporate history in 1993.
So we started by describing the difference between personal applications, group applications and enterprise applications. A personal application doesn’t have a database or any transactions, but rather reads its data into memory at the start and then writes the memory back out to a disk at the end. This is how Word, Excel, PowerPoint and Outlook work. Group applications allow for multiple users, so they tend to have a database and transactions, but they make a closed world assumption. That is how Exchange works for instance. To the extent that Exchange talks to the rest of the world, it is through SMTP and POP, application protocols. Enterprise applications have databases and transactions, but also make an open world assumption. They assume that it will be necessary to integrate with other applications for which there are no application protocols. These applications are used to do the record keeping and reporting of the enterprise whereas personal productivity and group applications are used for communications between people – email, document management and so on. Most CEOs never interact with such applications.
If you can get the CEO to recognise an enterprise application, you have a chance of explaining the role of enterprise architecture. This particular CEO has a problem that too much work has to be done by their people to make things happen in the enterprise. The reason for this is that their enterprise applications are not properly integrated. We see the same thing, for example, in banking where some banks achieve straight through processing for up to 96% of their transactions. That is, from the customer requesting the transaction to the transaction settling and clearing, only 4% needs human intervention. Some other banks, however, only achieve a 30% straight through processing rate, which means that they spend a lot more on people, take a lot longer to clear the transactions and make many more mistakes. So the next thing to explain to the CEO is the role the enterprise applications have in running the value chain. When a customer makes a request for something, that has to be recorded and then acted on. Typically, to act on the request, we first need to check the risk, usually by authorising funds from a credit card and by ensuring we have stock. Amazon used to act on requests while you waited (remember the screen saying ‘Please don’t press the back button while we check your credit card’) but, in order to scale, made this a separate operation. Finally, when the request is allowed, it is fulfilled by having a third system pick the goods and ship them. To get this to happen straight through the CEO first needs to have three enterprise applications: a customer facing one that takes orders (the Amazon Web site); a middle one that checks credit and stock; and a back office system that picks stock and ships it. These three enterprise applications then need to be integrated so that no people need to intervene to make things happen.
So what does enterprise architecture do for the CEO? In this case it puts together the enterprise applications so that they completely implement the value chain and maximise it straight through processing rate. This minimises cost, minimises re-work and maximises profit.
(Typed wrong email for last post)
This is very enlightening post, especially for the discussion on IBM. But I certainly also agree that enterprise architecture is more than just applications architecture, it also comprises business architecture, methods architecture etc. There is certainly more that could be discussed.
John, I would not extend this discussion for too long. After all this is your blog. Business requirements and vision are to be considered but you still need a business architecture to understand how the enterprise operates before looking at the IS.
Adrian G asks me who is going to do the BA (Business Architecture) for my clients. He rightly points out that BA is part of IAF (though I would call it a tier rather than a layer). This is a question that I ask every time I do an engagement. Often I have to point out to my clients that they need business change people with which to engage. In one engagement I even had to refuse to do design without any vision, scope or requirements. For some reason the people running the project thought it was possible to re-do the architecture of a bank without the bankers saying what they wanted it to be.
So the answer is you have to find the people responsible for funding change and get them to provide the product or change managers who will engage for the business while the enterprise architects engage for the information systems that support the business. It is usually a fatal error to annoint oneself the business architect because there is no one else stepping up to the plate. In the end, the architecture is driven by the projects that the business is prepared to fund. If you cannot get an explicit direction, you can at least get an implicit one.
Gentlemen,
Lets follow Adrian Campbells entomological approach for his definition of enterprise architecture with a little more rigour.
Acording to the collins dictionary we have these definitions,
Enterprise
1 > A project or undertaking, esp one that requires boldness or effort
2 > initiative in business
3 > a business unit; a company or firm
Architecture
1 > the art and science of designing and superintending the erection of buildings and similar structures
2 > a style of building or structure
3 > buildings or structures collectively
4 > the structure or design of anything
5 > the internal organization of a computer’s components with particular reference to the way in which data is transmitted
6 > the arrangement of the various devices in a complete computer system or network
Adrian Cambles and Adrian Grigoriu are essentially saying 1,4 where as John Sch. is in essence saying 2, 5
and unfortunatly Kevin Lee Smith is saying nothing as he neglected to provide his own definition.
I personally like to go back to the greek, architecture is the practice of the architet ot archi tekon, in english master builder.
And therefore any stanza that contains the word architectiure thus must contain an element of technical craft and design.
The act of business strategising and business modeleling refers to trade, which is conducted by business men(and of course women). Who hopefully execute this with the assistance of the excellent consultancy provided by Atos….
Maybe we need a new word?
“archibusinessman”
please remember,
The physician can bury his mistakes, but the architect can only advise his clients to plant vines.
ps.
personal applications are now highly transactional – e.g. google mail
John, GODS has already been applied to an airline and health insurance company. It’s in my book. But it is no use to you because you don’t care about business architecture, as admitted. But an EA without a BA is devoid of operational meaning.
Few CEOs would really listen to such EA IT exploits. CEOs rightly fail to understand why should they bother.
But who is going to do the business architecture of your customers? After all, the layer is included in the IAF framework. You don’t need that I assume because most CIOs would not require that. CEO would.
A business independent IS architecture does not solve your business customers problems, like process failure and duplication for instance, which are somewhere implemented in IS.
Your message seems to be: buy the application because 95% functionality is automated in there, don’t bother with humans and their processes.
Thanks for the comments. I certainly agree with most of what they say.
First of all, Kevin’s remark that EA is more than just IT EA. This is certainly the case. I particularly like the way the Integrated Architecture Framework from Capgemini separates Business and Information on the one hand, from Information Systems and Technology Infrastructure on the other. In this view of the world, IS is the bit of the business that is automated. My work is mainly about IS, not about technology infrastructure and there are few areas where I would be qualified to consult on business. It doesn’t worry me that I concentrate on IS as, so far, every EA department I have seen reports to the CIO of the companies that pay for them. To that extent I only really do IT EA, just as Kevin says.
Adrian tells me I need to learn more about enterprise architecture and I certainly agree with that too. I don’t think that enterprise architecture is the architecture of enterprise applications, but I do think business people need to understand what enterprise applications are in order to understand enterprise architecture. The reason for this is that increasingly it is the integration between enterprise applications that makes things happen in enterprises. My background in EA is mainly in financial services and particularly in automating middle offices for trading systems. Here banks aim for over 95% straight through trading and an order from the front office results in a cleared trade via a cascade of messages that integrate trade execution, positions, risk, books and records, clearing and settlement all without human intervention. Unless the CEO understands that, she is unlikely to get what the EA is doing for her.
Adrian is right that EA today is an IT discipline. Although I would love to be employed as a consultant for architecting enterprises, for most enterprises I would not be qualified. At the moment we are engaged at an auction house, a food manufacturer, and a higeer education organisation. I am qualified to talk to all of them about how to get the most out of their business systems, but for none of them about how to architect their businesses. In fact, in order to allow the IS to accomodate changes to the way the CEOs architect their businesses, I have to show them how to create IS that are agnostic to the operating model of the business. The “God’s Business Architecture” is interesting but it wouldn’t work for an investment bank or for a Global Distribution System in the airline business or for a government department, all of which I have done EA for.
John, I believe that a CEO would expect one to talk, at that level, about the Architecture of the Enterprise rather than that of its IT. In any case, since EA today is an IT discipline one will always fail to get the CEO’s and in general business’ attention.
The fact that you start from Value Chains, to put together your applications architecture, is a recognition of the fact that one needs a higher level business view of the IT architecture. A CEO may like to see that, but it has to be more than a Value Chain though.
Check this generic Business Architecture model at http://www.enterprise-architecture-matters.co.uk/gods-business-architecture
The model i extends the value chains model with business functions and flows maps.
John,
What on earth have so called ‘Enterprise’ Applications got to do with Enterprise Architecture?
No wonder your CIO was confused.
I think you need to learn more about Enterprise Architecture yourself before confusing other people about what it is.
Enterprise Architecture is NOT defined as the architecture of enterprise applications !!!
Enterprise Architecture is NOT the same as IT Architecture or Application Architecture !!!
The word Enterprise refers to the whole organisation and it’s immediate business environment, often including customers, partners and suppliers.
The word Architecture is about the overall design from a high level perspective, in particular concerning the design in the future and a roadmap to transition to that future.
Enterprise Architecture is concerned with everything in the enterprise from its business strategy and business model through to the execution of that strategy and implementation of the business model. That does include implementation of IT change with applications of various types but it’s just as much about the implementation of business change, if not more so these days.
Oh dear, dear, dear.
EA is much much much more than Enterprise Applications.
I think you are talking about Enterprise IT Architecture, not Enterprise Architecture.
It is articles like this that perpetuate the myth that is holding back Enterprise Architecture that it’s all about IT.
Richard, you are right that it was politics rather than engineering that drove what happened. And you are also right that there is more to EA than integration architecture. You might be interested in the IBM Systems Journal volume 27 issue 3 which was devoted to SAA and even has an article on user interfaces. The Common User Access that IBM developed and which became part of SAA was, and remains, an extremely important contribution to user interface design. Unfortunately, the politics and marketing ended up trumping the engineering behind SAA even though people as eminent as Al Scherr worked on it. It ended up nearly bankrupting the company and ensured that IBM would remain a laggard in IT for many years. Ironically, IBM has managed to put LINUX on the full range of its hardware. It was, I believe, the insistance that one operating system couldn’t cover the range that prompted SAA in the first place.
Looking on the Internet to find out more about Earl Wheeler, I found instead a criticism of Lou Gerstner from 1994, which made two interesting statements,
‘He proceeded to deliver a pitch which sounded ominously close to Earl Wheeler’s SAA (Systems Application Architecture). ‘
‘The “techie” tone of the speech also suggested that it was written by someone with an engineering and/or manufacturing mentality, not by a “business architect.” ‘
A preference for screen-scraping is clearly an act of technical architecture rather than business architecture. There may have been all sorts of political reasons for this preference, so we cannot conclude that it was reached out of pure technical ignorance, Indeed, the refusal to allow John to speak reinforces my suspicion that it was a political decision rather than a technical one.
However, today’s enterprise architecture practice has been significantly influenced by a body of work carried out at IBM and elsewhere, including the construction of artefacts like SAA, and the prevailing understanding of the relationship between business architecture and technical architecture is still dominated by the work of ex-IBM people like James Martin and John Zachman.
Clearly my friend John Schlesinger has far better ways of integrating enterprise applications these days, but I hope he’s not implying that this is all there is to enterprise architecture,
Richard, great question. To give you some more insight into how badly things went wrong, let me tell you the story of my presentation to Earl Wheeler at the SAA Vendor conference in January 1989. I was invited by Earl’s staff to give my presentation to them in October 1988 in Boca Rotan. I presented the idea that we would make it possible for end user interface logic, written in the SAA Dialog Manager, to execute procedures in CICS thereby enabling graphical user interfaces to use enterprise resources. His staff told me that “Earl doesn’t want to hear that message”. I asked what he did want to hear. The answer was ‘screen scraping’ using Earl’s preferred tool. I tried to explain that screen scraping would be a disaster and, far from being even a temporary solution, would make things much worse. The result was that they banned me from presenting but still let me show my demo. I had already put Distributed Program Link into CICS and for the demo we invented the External Communication Interface, which together enabled us to demo an OS/2 application using existing enterprise reources in CICS. Earl objected strongly to the demo as it did not show his screen scraping tool in action.
I put in place a plan to enable dialog management services in every CICS environment (at that time, MVS,VM, VSE and OS/2) and the enablement of dialog manager with CICS services. This plan was explicitly cancelled by the SAA people. The result was that CICS became a green screen only environment and most CICS applications were condemned to being accessed through Basic Mapping Support to this day. DPL and ECI are used primarily for integration not for writing new applications.
The people planning SAA were marketing people with no understanding of how information systems worked or what they were for. They never asked the development labs what it would take to create the SAA outcomes they wanted and when we tried to help them they wouldn’t listen. It is very similar to the story today with SOA.
John, could you expand from an enterprise architecture perspective on what you think was wrong with the IBM strategy in the late 1980s, and how enterprise architecture could have saved them. There were people at that time who were doing things we’d now label as enterprise architecture, within IBM and elsewhere, but these were the very people who were building SAA. If IBM had had a full enterprise architecture function at that time, surely its role would have been far more than just “putting together the enterprise applications so that they completely implement the value chain and maximise it straight through processing rate”.
You attribute the failure of the IBM strategy to ignorance among IBM executives of what you call “enterprise applications”. But I think it makes more sense to attribute this failure to ignorance among IBM’s customers, and to IBM’s failure to communicate the advantages of SAA to its customers. The people in the customers who would have been most likely to understand the potential advantages of SAA would have been enterprise architects, if these had existed in those days; IBM’s error was to build a product for which the market didn’t yet exist.