Aggregated enterprise architecture wisdom
Big Data is the Big Thing at the moment. It won’t be ten years from now. And not because we tackled the technical aspects of handling it, or created huge business intelligence systems capable of harvesting the treasures hidden in it. Or because it has become generally accepted and arrived at Gartner’s plateau of productivity. […]
Subhead: Modernization is NOT Optional!
Once again customers of The Royal Bank of Scotland (RBS) and its subsidiaries Ulster, Natwest etc are in trouble! Unable to use their debit cards, or access their funds! And the new Chief Executive Ross McEwan admitted today that RBS has failed to invest properly in its systems for decades! RBS has given no explanation of the crash, except that it was not related to the high volumes of transactions on Cyber Monday.
Actually the root problem for RBS, and many other banks and other very large organizations, is NOT that they haven’t invested in their systems for decades. The problem is that they have allowed the systems to evolve without good architecture and governance. Banking systems in particular used to be leading edge. But over the years the core systems that actually run the bank, have become badly out of date. Instead of modernizing the core systems, many banks have responded to demand for new products and services by surrounding the old legacy systems with new bolt on systems. As a result the old systems are held together with sticky tape and sealing wax, and modified piecemeal to adjust to new requirements, and the new systems create more and more interfaces and dependencies (including duplicated, hard coded business rules), so that eventually the systems resemble a hair ball. And as you know, a hairball is a tightly packed cylinder of fur, which also includes all manner of foreign particles, which can be quite hazardous in humans and animals. In systems terms we would more usually refer to the resulting mess as a monolithic systems portfolio.
The root problem therefore is twofold:
1. The increasing complexity and risk inherent in making change.
2. Increasing horizon of any change.
And the issues become apparent either when extremely complex operational processes execute incorrectly, or when changes in process, software or environment are made, often unavoidably without full knowledge of all the implications due to lack of experience, documentation or even code!
Although I have no doubt that in all the large banks there are fierce debates about the IT budget, strangely the solution to this problem isn’t about the amount of money that needs to be spent. Rather it’s about how the organization embraces a real modernization program, which is led by good architecture and managed with strong governance.
Sadly in the IT industry the term modernization has come to mean something quite specific – the re-platforming or technology upgrade of some application. Whereas modernization should really encompass a much broader remit including:
1. Establishing a lingua franca between business and IT so that modernization issues and implications are genuinely understood by both business and IT management.
2. Defining a business systems architecture that a) facilitates transformation with low risk and b) progressively develops an inherently agile architecture, that can evolve continuously.
3. A roadmap for progressively rationalizing the business systems portfolio to comply with the architecture.
4. Implementing an integrated business and IT organization that owns the business systems.
5. Implementing knowledge management around business systems that ensures integrity and consistency and ownership of processes, information and rules.
6. Implementing a continuous Agile modernization and ongoing evolution process in both business and IT.
7. Establishing coordination, governance and risk management that ensures architectural integrity at all stages of the life cycle.
It would be easy for business management to think that the sort of problems experienced by RBS and other banks as IT problems. The above list suggests this is nonsense. The only way to properly resolve the issues is for business management to accept co-responsibility for IT. And it’s no accident that the first point in the list above is to ensure that business management understand the issues they are dealing with, and can communicate effectively with the IT organization. This isn’t just attending an education class; it’s embracing a common language that allows critical decisions to be taken on a properly balanced understanding of business and IT assumptions, costs and risks.
Retailers, manufacturers, power companies, logistics companies, government departments etc etc should not be complacent or smug when they see the problems at the banks. In fact almost all very large organizations have these problems. And the message for all enterprises is Modernization is not Optional!
Links:
RBS Crash – Management Prefer Offshoring to Modernization?
CBDI Journal Reports on Modernization
Many enterprise architects are modest (otherwise a great quality!) and feel awkward when they have to toot their own horn, the “value horn”, if you will…Shouldn’t our work speak for itself? What value is there in being pompous and blowing our own hor…
The Zachman one-day seminar is a full day of John Zachman talking about Enterprise Architecture and the Zachman Framework™. This day is part of our FEAF program. John spends time and develops the ideas around Enterprise Physics, the desperate need for Enteprise Architecture, the misconceptions around the Zachman Framework in addition to the EA ontology and how to implement it’s concepts.
 |
Zachman® One-Day Seminar View Syllabus |
|
|
|
|---|---|
| Zachman One-Day Seminar | $299 |
The Zachman one-day seminar is a full day of John Zachman talking about Enterprise Architecture and the Zachman Framework™. This day is part of our regular DoDAF and FEAF programs. John spends time and develops the ideas around Enterprise Physics, the desperate need for Enteprise Architecture, the misconceptions around the Zachman Framework in addition to the EA ontology and how to implement it’s concepts.
 |
Zachman® One-Day Seminar View Syllabus |
|
ZACHMAN CERTIFIED™ – ENTERPRISE ARCHITECTURE PROGRAM
|
|
|---|---|
| Zachman One-Day Seminar | $299 |
During October I ran a survey asking Architects, Designers and Project Managers about Service Specification practices. I have just completed the analysis and report, see link below. There are some interesting conclusions:
1. DIY is the dominant service specification approach.
Respondents report there’s a wide range of approaches to service specification in use, and the most common approach by far (50%) is “do it yourself”. Sure, DIY will mean that practitioners are like magpies, they pick up ideas from a variety of sources, and create their own capability. But this, by any measure, must represent a failure of industry standards. While consistency of specification meta data may not be a primary goal for designers and developers, architects should consider a range of risks including use of development automation support tools, standardization of technical components of outsourcing contracts, opportunity to find/reuse pre-existing services, and crucially standardization of tooling. Which takes me onto the next point . . .
2. Documents and Spread-sheets still dominate tool usage for service planning, reporting and management.
In the early stages of service adoption almost everyone simply uses the tools that are available to hand. But as the service portfolio evolves and matures these tools become a strategic liability in areas of planning, reuse management, portfolio and asset management, governance and reporting. I note not one respondent mentioned the EA Repository in context with service support tools. And again this is closely connected with the third interesting conclusion . . .
3. 64% dissatisfied with tool support.
There was a very high level of dissatisfaction with tools, particularly in the context of communicating service specifications between the different roles and groups across the organization. We all appreciate high quality service specifications are the result of multi-disciplinary efforts, spanning Business Analysis, Architecture, Design, Developers, Product Management, IT Service Management, Outsourcing, Procurement, Governance etc . So this is much more than reporting, there’s an evident need for modern tools that facilitate the collaboration process.
Chess Grandmasters master the application of concepts and apply them to situations. I study chess and learn move sequences for Openings, Middle Game, Endings, etc and witness many people get caught up in debates around move sequences. There seem to be endless debates which opening is the best defense for specific offense openings….
(skiplumley’s question refers to this post: What is Architecture)
There isn’t any strong reason to avoid using the word essence to describe something definitive.
As long as we recognise that ‘essence’ is a philosophical term. It’s meaning depends on o…
As the Cowardly Lion once remarked, “I do believe in ghosts, I do, I do, I do believe in ghosts!” In the technology space, ghosts are fateful decisions, implicit or explicit, that are buried within a solution until the right set of circumstances raise them from the dead.
For instance, in January 1990, AT&T experienced a cascade of failures in their long distance network switches. It seems
All too often in the growth and maturation of EnterpriseArchitecture initiatives, the effort stalls or is delayed due to lack of “appliedtraction”. By this, I mean the EAactivities – whether targeted towards compliance, risk mitigation or valueopportunity propositions – may not be attached to measurable, active, visibleprojects that could advance and prove the value of EA. EA doesn’t work by itself, in a vacuum,without collaborative engagement and a means of proving usefulness. A criticalvehicle to this proof is successful orchestration and use of assets and investmentresources to meet a high-profile business objective – i.e. a successfulproject.
More and more organizations are now exploring andconsidering some degree of IT outsourcing, buying and using external servicesand solutions to deliver their IT and business requirements – vs. building andoperating in-house, in their own data centers. The rapid growth and success of“Cloud” services makes some decisions easier and some IT projects moresuccessful, while dramatically lowering IT risks and enabling rapid growth.This is particularly true for “Software as a Service” (SaaS) applications,which essentially are complete web applications hosted and delivered over theInternet. Whether SaaS solutions – or any kind of cloud solution – areactually, ultimately the most cost-effective approach truly depends on theorganization’s business and IT investment strategy.
This leads us to Enterprise Architecture, the connectivitybetween business strategy and investment objectives, and the capabilitiespurchased or created to meet them. If anEA framework already exists, the approach to selecting a cloud-based solutionand integrating it with internal IT systems (i.e. a “Hybrid IT” solution) iswell-served by leveraging EA methods. If an EA framework doesn’t exist, or issimply not mature enough to address complex, integrated IT objectives – ahybrid IT/cloud initiative is the perfect project to advance and prove thevalue of EA.
Why is this? For starters, the success of any complex ITintegration project – spanning multiple systems, contracts and organizations,public and private – depends on active collaboration and coordination among theproject stakeholders. For a hybrid IT initiative, inclusive of one or morecloud services providers, the IT services, business workflow and datagovernance challenges alone can be extremely complex, requiring many diverse layersof organizational expertise and authority. Establishing subject matterexpertise, authorities and strategic guidance across all the disciplinesinvolved in a hybrid-IT or hybrid-cloud system requires top-level,comprehensive experience and collaborative leadership. Tools and practicesreflecting industry expertise and EA alignment can also be very helpful – suchas Oracle’s “Cloud Candidate Selection Tool”.
Using tools like this, and facilitating this criticalcollaboration by leading, organizing and coordinating the input and expertiseinto a shared, referenceable, reusable set of authority models and practices –this is where EA shines, and where Enterprise Architects can be most valuable.The “enterprise”, in this case, becomes something greater than the coreorganization – it includes internal systems, public cloud services, 3rd-partyIT platforms and datacenters, distributed users and devices; a whole greaterthan the sum of its parts.
Through facilitated project collaboration, leading toidentification or creation of solid governance models and processes, a durableand useful Enterprise Architecture framework will usually emerge by itself, ifnot actually identified and managed as such. The transition from planningcollaboration to actual coordination, where the program plan, schedule andresources become synchronized and aligned to other investments in theorganization portfolio, is where EA methods and artifacts appear and becomemost useful. The actual scope and use of these artifacts, in the context ofthis project, can then set the stage for the most desirable, helpful andpragmatic form of the now-maturing EA framework and community of practice.
Considering or starting a hybrid-IT orhybrid-cloud initiative? Running into some complex relationship challenges? Thisis the perfect time to take advantage of your new, growing or possibly latent EnterpriseArchitecture practice.
In July 1989 the Harvard Business Review published a seminal article by Chase and Garvin titled The Service Factory [1]. They argued that “The factory of the future is not a place where computers, robots, and flexible machines do the drudge work. . . the next generation, then, will compete by bundling services with products, anticipating and responding to a truly comprehensive range of customer needs.”
Since the publication some 25 years ago, much has happened to validate Messrs Chase and Garvin’s thesis. The world has manifestly transformed into a “service based world”. By some accounts the service sector grew to over 80% of the US economy by 2000. There are various implementations of the Service Factory concept; we might observe that the ubiquitous Call Centers represent a scalable, repeatable factory model. Similarly in the technology world services, or APIs, are a central part of many IT architectures, and some firms have adopted a service factory model by separating service and solution delivery.
But it must be said that for most enterprises there remains a significant gap between the business and software services. Over 25 years ago Chase and Garvin recognized this as an issue. They use the example of how 200 years ago horse-drawn carriages were mostly made by craftsmen, and the most successful carriage maker was invariably the most accommodating for the customer. But as mass production overtook craftsmanship customers came to value standardized, lower price more than higher price, personalized products. Gradually manufacturing became separated from pre and post-sale customer facing activities. In recent years in some industry sectors, there has been a noticeable reversal of this trend, and mass customization is widely practiced. However in many industries, notwithstanding Agile methods focus on customer involvement, the design of business services remains a discrete activity from the architecture and design of IT services.
This is starting to change. The Mobile revolution and the Internet of Things will inevitably cause a convergence of business and software services. I have described this as “turning the business inside out”. In future it will be a very rare business service that isn’t delivered by a software service, at least as an option or complement. It’s a racing certainty that Call Centers and other conventional service delivery models are going to go the same way as Telephone Exchanges, Typing Pools and Airline Reservations Departments! In this fast emerging world, “everything is a service”. And this will have a profound impact on the shape of the Service Factory of tomorrow.
The Service Factory 2.0 will be a software factory separate from solution delivery projects. As discussed some firms already employ this organizing model in order to architect and design services to standardize core business information and rules for use in many processes.
The software factory concept has been in use for some time, particularly in conjunction with the Product Line concept, where common components are delivered using a framework of tools, repeatable processes and patterns, that are reused in solutions supporting the Product Line. The Service Factory 2.0 is a specialization of the software factory, with a framework that is specific to services. However the most effective service factory will also be a “business service” delivery model in which the life cycle of the business, software and IT service perspectives are integrated.
We can anticipate a number of critical innovations that will enable the Service Factory 2.0:
1. Everything is a Service All business capabilities are delivered as modular software services which are integral to the holistic business service offering.
2. Automated Requirements Capture. The requirements activity is automated in a manner that facilitates the involvement of the real stakeholders in the specification of the business, software and IT service, in a language that is entirely natural to them and to engage meaningfully in distributed Agile processes.
3. Automation of Common Service Patterns. The Service Factory frameworks that bootstrap service implementations will increasingly automate many of the common architectural and business model styles. Yet unlike the de facto application package products, the Service Factory will facilitate the extension and customization of the common pattern to allow competitive differentiation for the customer organization, as well as ongoing flexibility.
4. Service Portfolio Management. The Service Factory must support the management of the “business service” and provide tools that integrate demand management, architecture and governance over a composable and constantly evolving business and software service portfolio.
6. Pattern R&D. An important role of the service factory will be to continuously evolve patterns to enable and support innovation in styles of business service together with increased scope of automation coverage
7. Architecture Managed Iteration. Pattern based development delivers code that is always compliant with the architecture, but also with meta data that allows full automation of configuration management. This facilitates continuous, low effort iteration in the delivery, test, DevOps cycle and evolution in production.
In their paper, Chase and Garvin quote Drucker who noted that the imperatives of information-based competition are breaking down barriers within businesses and making functional divisions obsolete. To my mind, the primary characteristic of Service Factory 2.0 will be the realization of the business, software and IT service as a composite offering, architected, designed and delivered as a business asset.
Link: Everware-CBDI Service Factory as a Service
Image if you could plan your next vacation by taking your favorite beach, with your favorite amusement park, your favorite restaurant, favorite mini-golf, favorite ski slope, bowling alley, go-cart race track, hotel suite, and of course cruise line…
