Aggregated enterprise architecture wisdom
Standards can be a powerful tool to get to grips with certain aspects of our work. However, managing a standards base appears to be tricky: we see many initiatives fail, despite the best intensions of all involved. In this short recording we will disc…
Another month, another enterprise-architecture conference? This time it was Open Group London, billed as “Business Transformation in Finance, Government and Healthcare”. Of which it did cover some – according to the programme and the Twitterstream, anyway. (See the Open Group’s ‘highlights’…
Roadblocks Cloud computing, which is part of the widespread adoption of a Service Oriented Business approach, becomes pervasive, and is rapidly evolving with new propositions and services. Therefore organisations are faced with the question how these various cloud propositions from … Continue reading →
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.
All too often in the growth and maturation of Enterprise
Architecture initiatives, the effort stalls or is delayed due to lack of “applied
traction”. By this, I mean the EA
activities – whether targeted towards compliance, risk mitigation or value
opportunity propositions – may not be attached to measurable, active, visible
projects 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 critical
vehicle to this proof is successful orchestration and use of assets and investment
resources to meet a high-profile business objective – i.e. a successful
project.
By Dr. Chris Harding, The Open Group The results of The Open Group Convergent Technologies survey point to secure integration of the technologies as a major challenge for Open Platform 3.0. This and other input is the basis for the … Continue reading →
I recently had the pleasure of joining a discussion among organizational development professionals. During that discussion, one individual asked an interesting question: in a distributed organization with multiple operating units, spread geograph…
By Loren K. Baynes, Director, Global Marketing Communications We eagerly jumped into the second day of our Business Transformation conference in London on Tuesday October 22nd! The setting is the magnificent Central Hall Westminster. Steve Nunn, COO of The Open … Continue reading →
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
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 Servicehttp://agileservicefactory.com
My advice: discard the title of EA. Find what what the employer wants and recruit accordingly.
What is the define problem definition phase?Improvement projects focus on solving a problem. A problem occurs when an actual situation and the desired situation dont match. We define the problem in a problem statement. It is imperative that this state…