Aggregated enterprise architecture wisdom
(Note: I’ve added an addendum to this post)
It has been many years that we have lived with the concept of technical debt. Martin Fowler did a good job of describing the concept in a 2003 article on his wiki. Basically, the idea is that you …
It’s not about the methods, it’s not about models, it’s not about the tools – it’s about having the ability to make smarter decisions. Those decisions might be related to improving business operations or processes, undertaking significant business transformations, merging organizations, or any one of the hundred and one other projects that we seem to need to deliver by yesterday!
Related posts:
Related posts brought to you by Yet Another Related Posts Plugin.
In the world of Enterprise Architecture, we are still creating “shared” understanding of how to tell our stakeholders what we do. There is no consistency in our diagrams or our descriptions just yet. This post will discuss the different ways we present the value stream of Enterprise Architecture and will attempt to select a particular viewpoint that can be useful for the majority of situations.
First, let’s address the most commonly shared representation: TOGAF. The TOGAF ADM model illustrates a sequence of activities that starts with a preliminary phase and works its way through each of the levels of architecture. Basically, TOGAF illustrates a straight-through process from phase A through phase H to develop and use architecture.
First off, I’m no huge fan of this illustration. I always wondered how you get to an architectural vision prior to considering the architecture of the business. Also, the notion of a center point focused around requirements management feels weirdly tactical. At the level of an Enterprise Architect, I’m dealing with strategies and measures of success. At the level of a technical architecture, the word “requirements” has an altogether different meaning. Grouping together the notion of “strategic needs” with “technical requirements” may make sense to a technologist, but I don’t know a single business stakeholder of EA that would agree with grouping those two rather distinct things.
These observations bring me to my first key consideration: If we want to communicate the value stream of Enterprise Architecture, we first should consider the audience, “who are we communicating to?” If we are communicating to a stakeholder of EA, we should show them the bits of EA that are relevant to them, and we should not show them the bits that are not.
It is not cynical to gloss over the complex bits of EA when talking to a business stakeholder… it is practical. In fact, we do it all the time. If you buy cable TV services, a person from the cable company may come to your house and install a coax cable to your home. He will mess around with a cable box for a few minutes, and then, if you are lucky, he will show you how to do simple things like changing channels and recording your favorite shows. Then, he’s off. He does NOT spend an hour describing the various technical aspects of signal transmission and digital carrier signals. Why should he? You don’t care. You want to watch TV, not get a degree in electrical engineering. And the same applies to EA.
Secondly, if we want to communicate EA, let’s recognize that different people interact with Enterprise Architecture in different ways. Business stakeholders will interact with Enterprise Architecture to ensure that their strategies are being executed effectively, with minimal interference, and producing a result that considers things like security, cost of ownership, and the ability to cope with rapid changes in the marketplace.
Recap:
The ADM from TOGAF is an odd bird, because it attempts to be all things to all people. It represents EA in a way that every stakeholder can use, but honestly, no stakeholder can use it. It is not wrong. Far from it. But it is not useful because it violates every single one of the rules above. The ADM reflects the EA viewpoint, but not the viewpoint of the customers of EA at a level that they can grasp, understand, and most importantly, use. So let’s keep the ADM in our court, and create a view of the EA process that is relevant to our stakeholders.
So who are our stakeholders? For the sake of this post, I’m going to select one set of stakeholders and ignore the rest. Is that correct? Nope, but it is practical for a blog post. What this means is that the rest of this post produces an answer of the “right” representation only for one class of stakeholders… another representation would likely be needed for different people. That is the nature of EA. Let’s not fret it.
There is a widely held view in Enterprise Architecture that an EA must be technically savvy in order to be effective. There are certainly business architects who are quite effective who are not technologists, but in order to move UP to the notion of an EA (which includes business architecture, information architecture, solution or application architecture, AND technology architecture), you would need to be technically capable.
I won’t belabor the point about whether it is correct to view Business Architecture as a subset of Enterprise Architecture. It is the wildly predominant view. (A poll that I put on LinkedIn that asked this question found that well over 80% of EA respondents agree that EA generally includes every aspect of business architecture. That’s pretty overwhelming.)
That said, our biggest struggles in EA rarely involve conversations with other architects. While there may be a great deal of confusion, there is rarely a lack of buy-in for architecture among architects, or even technologists. Our key challenge, when it comes to communication, comes when we are talking to non-technologists. In other words, the proverbial “business” stakeholders of EA. (Please don’t flame me about whether IT is part of the business or not. That is a useful conversation, but it is outside the scope of this post).
Therefore, for the rest of this post, I will focus on the non-technology stakeholders of Enterprise Architecture. These are people whose chief concerns are not technical concerns. We could say that they care about financial performance, role clarity, cycle time, cost effectiveness, market position, revenue growth, opportunity costs, business drivers, and many other factors outside the realm of technology concerns. People in this category include senior business leaders (CEO, COO, CFO, CIO, CMO, etc), as well as business unit leaders (General Managers, Sales Division Leaders, Product Development and Marketing, Customer Service, Online Services, etc).
In order to communicate directly and well to these folks, lets recognize that they don’t care about the aspects of architecture that are technology focused. While the WANT good technology, and will BENEFIT from good technology, they will assume that the technology issues can be handled effectively without bothering them with details. To refer to our previous metaphor, they want the cable company to handle the technology, so that they can deal with changing channels.
So, let’s take the ADM, and trim out the stuff that non technologists rely on, but don’t need to have a conversation about. They assume it is there. That includes the preliminary stage, as well as architectural vision, requirements management, information systems architecture, technology architecture, and architecture change management.
The ADM now looks a bit different. In fact, we can put it in a single row with a looping arrow. Note that, in TOGAF, the Business architecture phase includes both current state assessment and future state modeling.
We have removed the confusing bits from the view of the non-technical stakeholder, but it is tough to say that we are at the point where we are relevant. After all, the non technical stakeholder has a business process that he uses when working with changes to his or her business. We are not representing that process.
The process, frequently described in dozens of bits of EA literature, starts with an understanding of the current situation within the business. Then, when the business creates a strategy, we bring these two bits of information together (current state and strategy) to create a vision for the future. This is the order that the non technical stakeholder may recognize… not the generalized view of the ADM. So it is time to break apart and rearrange the bits a little bit. I will now step away from the “crop circles” representation since it is so far out of the experience of people who describe business processes.
In this view, we can begin to see the steps that an Enterprise Architect would perform that are visible to a non-technical stakeholder. Just for the sake of clarity, this doesn’t mean that the technical steps are absent… it just means that our technical efforts don’t have to be paraded around in front of our non-technical stakeholders.
Note that I relabeled the ADM steps.
Let me point out that the TOGAF process assumes a different order of activities than the diagram above. From the standpoint of the stakeholder, this is what makes sense, regardless of how TOGAF describes the stages. This is why I’m no big fan of TOGAF as a methodology. It doesn’t reflect reality. On the other hand, the elements above are fairly well understood.
Also note that I’m not saying that the substitutions listed above are equivalent. In fact, I’d argue violently that Business Architecture is far more than Current state evaluation and Strategy Development. However, from the viewpoint of the non-architect, business architecture is a process that is involved with the development of business models (current and future), and that’s about it. There is a great deal of effort that is not seen by the stakeholders.
In other words, the blue model above is only showing the tip of the iceberg, and relabeling the phases according to what is (approximately) visible, not what is actually there.
This is an important part of explaining an activity to a stakeholder, and it is a skill that every Enterprise Architect must get good at. You have to explain your activities in the context of what a stakeholder understand and recognizes… not in the context of all your work. It’s not about you. It’s about the stakeholder.
There are a few problems with the view above. In order to understand the problems with that view, let’s mention a couple of rules for representing a value stream. We will use these concepts because the ability to describe EA in terms of a value stream is important. Value streams are sticky… they are easy to remember and easy to relate to. If we want to remove the barriers to adoption of EA, we could do far worse than using this technique. That said, there are some rules that we have to keep in mind:
So let’s apply rule #1. Is it true that the current state of the organization actually feeds the development of strategy? No. In fact, the evaluation of the current state can happen completely in parallel to the development of business strategy.
So the diagram could look like this one.
Here, we can see that there are, in fact, parallel activities for the understanding of the current state of the enterprise, and for the development of business strategy. Where they first intersect is in the development of the future state (the opportunities and solutions phase from the ADM model). You need both an understanding of the current situation and the needs of the future in order to describe where the organization should move towards.
Now, let’s apply rule #2. What is the event that the business considers to be relevant to start the value stream of Enterprise Architecture? The Development of Business Strategy, of course. So the flow should perhaps look more like the diagram below… (note, the arrows and activities are identical to the one above… the only thing different is the order on the page).
Now, let’s apply rule #3… that one is easy. The arrow at the bottom that says “First TIme EA” can simply be dropped. After all, the first time a process is run, it starts from somewhere. It is simply irrelevant to the non-technical stakeholder to point out where that starting position is.
Exception: if you run Enterprise Architecture as a consulting arrangement, you may want to leave that arrow in there. After all, you will need to illustrate where the consulting arrangement will start. That said, I have found that fewer and fewer EA initiatives begin with the hiring of a consulting firm.
When we started with the ADM, we assumed that there was a 700+ page methodology and framework behind the image, describing each step and what is included. However, your stakeholder will not read the TOGAF or any other 700+ page body of information. That would be absurd. You need to add a little detail to the image to describe what is in each of these stages.
It’s also a good idea to “clean up” the diagram a little so that we use less space on the “arrows and boxes” and more engagement on the ideas of what is going on. So the next modification of the process looks like this:
This diagram is a better one for informing the non-technical stakeholders of your Enterprise Architecture program about what it is that you do. We remove a little of the “accuracy” about where an arrow starts and ends, but we add a great deal of context about what is happening along the way.
The “backward” arrow along the bottom clearly indicates that there are activities that flow outside the value stream but which are needed for each repeat of the cycle.
Is this a perfect representation of the EA process? I don’t believe in perfect things… just useful things. But it is better, in my opinion, than showing a non-technical stakeholder the ADM or one of the “box and arrow” models above. It uses the visual language of value streams and business process models, both widely recognized and used in business interactions. It explains itself without going into a lot of detail. And it clearly describes the end to end flow without restricting or dictating where Enterprise Architects start and stop (an important requirement, since maturing EA programs will change their scope as they mature).
I have shown this view to others, and some have wondered about the “backward flowing” process along the bottom. The alternative to showing something as “backward flowing” would be to illustrate it as a cycle (with arrows feeding “in” from the right and “out” from the left). If it is a challenge for you to view the diagram without those arrows, I apologize. I’d love to see other view of this model that illustrate the “cycle” in a way that still meets the “rules of the value stream” as discussed above.
I’d love to get feedback and insight from the community. What do you think? Does the last image above resonate? What would you do differently?
Was it Lisbon that attracted me so much or the word Cybernetics in the sub-title or the promise of Alberto Manuel that it would be a different BPM conference? May be all three and more. As it happened, the conference was very well organised and indeed different in a nice way. The charm of Lisbon […]
Enterprise architects and consultants often enjoy building specific languages. This is both good and bad. Good jargon allows one to be very specific and concisely articulate observations about a particular specialised field of interest — for instance a domain architecture or a very specific business process, which only few people understand or carry out. Bad …read more
Note: This is an old post from my previous blog, Thinking Enterprise, which I have moved over to this blog. The original blog post is dated July 7 2012. What are the values of a good enterprise architect? Being in a consulting practice where I spend the most of my working life collaborating with CIO’s, …read more
The primary structuring element for SOA applications is a service as distinct from subsystems, systems, or components. A service is an autonomous and discoverable software resource which has a well defined service description.
SOA is based on a fundamental architectural model that defines an interaction model between three primary parties, the service provider, who publishes a service description and provides the implementation for the service, a service consumer, who can either use the uniform resource identifier (URI) for the service description directly or can find the service description in a service registry and bind and invoke the service. The service broker is the third party who provides and maintains the service registry in addition to providing mediation services between providers and consumers.
In 2012, the use of SOA for pivotal emerging technologies, especially for mobile applications and cloud computing, suggests that the future prospect for SOA is favourable. SOA and cloud will begin to fade as differentiating terms because it will just be “the way we do things”. We’re now at the point where everything we deploy is done in a service-oriented way, and cloud is being simply accepted as the delivery platform for applications and services. Also many enterprise architects are wondering if the mobile business model will drive SOA technologies in a new direction. Meanwhile, a close look at mobile application integration today tells us that pressing mobile trends will prompt IT and business leaders to ensure mobile-friendly infrastructure.
To be successful in implementing a SOA initiative, it is highly recommended that a company create a Center of Excellence and the Open Group clearly explains how this can be achieved through the use of TOGAF 9.1. This article is based on the specification and specifically the section (in italics) 22.7.1.3 Partitions and Centers of Excellence with some additional thoughts on sections 22.7.1.1 Principle of Service-Orientation and 22.7.1.2 Governance and Support Strategy.
I have looked at the various attributes and provided further explanations or referred to previous experiences based on existing CoEs or sometimes called Integration Competency Centers.
The figure below illustrates below a SOA Center of Excellence as part of the Enterprise Architecture team with domain and solution architects as well as developers, QAs and business architects and analysts coming from a delivery organization. 
This center of excellence support methodologies, standards, governance processes and manage a service registry. The main goal of this core group is to establish best practices at design time to maximize reusability of services.
Below is then what is written in the TOGAF 9.1 specification.
A successful CoE will have several key attributes:
Any SOA Center of Excellence must have a purpose. What do we want to achieve? What are the problems we need to solve?
It may sound obvious, but having a blueprint for SOA is critical. It’s very easy for companies, especially large enterprises with disparate operations, to buy new technologies or integrate applications without regard to how they fit into the overall plan. The challenge in building a SOA is to keep people, including IT and business-side staff focused on the Enterprise Architecture goals.
In order to realize the vision of SOA the following topics should be addressed:
· What to build: A Reference Architecture
· How to build: Service-Oriented Modeling Method
· Whether to build: Assessments, roadmaps, and Maturity evaluations
· Guidance on Building: Architectural and Design patterns
· Oversight: Governance
· How to build: Standards and Tools
The Center of Excellence would first have a vision which could be something like:
“ABCCompany will effectively utilize SOA in order to achieve organizational flexibility and improve responsiveness to our customers”.
Then a mission statement should be communicated across the organization. Below a few examples of mission statements:
“To enable dynamic linkage among application capabilities in a manner that facilitates business effectiveness, maintainability, customer satisfaction, rapid deployment, reuse, performance and successful implementation.”
“The mission of the COE for SOA at ABCCompany is to promote, adopt, support the development and usage of ABCCompany standards, best practices, technologies and knowledge in the field of SOA and have a key role in the business transformation of ABCCompany. The COE will collaborate with the business to create an agile organization, which in turn will facilitate ABCCompany to accelerate the creation of new products and services for the markets, better serve its customers, and better collaborate with partners and vendors.”
The Center of Excellence would also define a structure and the various interactions with
· the enterprise architecture team
· the project management office
· the business process/planning & strategy group
· the product management group
· etc.
And create a steering committee or board (which could be associated to an architecture board).
They will provide different types of support:
· Architecture decision support
o Maintain standards, templates and policies surrounding Integration and SOA
o Participate in Integration and SOA design decisions
· Operational support
o Responsible for building and maintaining SOA Infrastructure
o Purchasing registries and products to grow infrastructure
· Development support
o Development of administrative packages and services
o Develop enterprise services based on strategic direction
Measurements and metrics will have to be identified. The common ones could be:
· Service revenue
· Service vitality
· Ratio between services used and those created
· Mean Time To Service Development or Service change
· Service availability
· Service reuse
· Quality assurance
· Etc.
Clearly comprehensive testing activities must be described by the Center of Excellence. In addition to a set of defined processes related to Web Service Definition Language (WSDL) testing, functional unit testing, regression testing, security testing, interoperability testing, vulnerability testing and load, performance testing, an analysis tool suite may be used to tailor the unique testing and validation needs of Service Oriented Architectures.
This helps test the message layer functionality of their services by automating their testing and supports numerous transport protocols including: (here a few examples) HTTP 1.0, HTTP/1.1, JMS, MQ, RMI, SMTP, .NET WCF HTTP, .NET WCF TCP, Electronic Data Interchange, ESBs, etc.
Only by adopting a comprehensive testing stance, enterprises can ensure that their SOA is robust, scalable, interoperable, and secure.
The Center of Excellence will promote best practices, methodologies, knowledge, and pragmatic leading-edge solutions in the area of SOA to the project teams.
This may sounds like a good idea but I have never seen this as an applied practice.
Competency and skills building is needed for any initiative. SOA is not just about integrating technologies and applications but it is a culture change within the enterprise which requires IT to move from being a technology provider to a business enabler. There may be a wide range of skills required such as:
· Enterprise Architecture
· Value of SOA
· Governance model for SOA
· Business Process Management and SOA
· Design of SOA solutions
· Modeling
· Technologies and standards
· Security
· Business communication
· Etc.
It has to be said that lack of SOA skills is the number one inhibitor to SOA adoption.
Here again, I am not sure that I have observed any Center of Excellence being closed…
The Center of Excellence will then also define a Reference Architecture for the organization.
A Reference Architecture is an abstract realization of an architectural model showing how an architectural solution can be built while omitting any reference to specific concrete technologies. Reference Architecture is like an abstract machine. It is built to realize some function and it, in turn, relies on a set of underlying components and capabilities that must be present for it to perform. The capabilities are normally captured into layers which in their own right require an architectural definition. However, the specific choice of the components representing the capabilities is made after various business and feasibility analysis are performed. A Reference Architecture can be used to guide the realization of implementations where specific properties are desired of the concrete system.
The purpose of the Reference Architecture is reflected in the set of requirements that the Reference Architecture must satisfy. We can structure these requirements into a set of goals, a set of critical success factors associated with these goals and a set of requirements that are connected to the critical success factors that ensure their satisfaction.
A Reference Architecture for SOA describes how to build systems according to the principles of SOA. These principles direct IT professionals to design, implement, and deploy information systems from components (i.e. services) that implement discrete business functions. These services can be distributed across geographic and organizational boundaries, can be independently scaled and can be reconfigured into new business processes as needed. This flexibility provides a range of benefits for both IT and business organizations.
Using the pattern approach the SOA Reference Architecture is a means for generating other more specific reference architectures, or even concrete architectures depending on the nature of the patterns. Or to put it another way, it is a machine for generating other machines.
The Open Group Standard for SOA Reference Architecture (SOA RA) is a good way of considering how to build systems.
The center of Excellence needs also to define the SOA life cycle management which consists of various activities such as governing, modelling, assembling, deploying and controlling/monitoring.
Simply put, without management and control, there is no SOA only an “Experience”. The SOA infrastructure must be managed in accordance with the goals and policies of the organization, which include hardware and software IT resource utilization, performance standards as well as goals for service level objectives (SLOs) for the services provided to IT users as well as business goals and policies for businesses that run and use IT. To be truly agile, enactment of all these different types of policies requires automated control that allows goals to be met with only the prescribed level of human interaction.
For every layer of the SOA infrastructure a corresponding Manage and Control component needs to exist / be in place. Moreover, the “manage and control” components must be integrated in a way that they can provide an end-to-end view of the entire SOA infrastructure.
These manage and control functions provide the run-time management and control of the entire enterprise IT execution environment. This includes all of the enterprise’s business processes and information services, including those associated with the IT organization’s own business processes.
The “Principle of Service orientation” must exist as defined in 22.7.1.1 Principle of Service-Orientation, but lower levels of principles, rules, and guidelines are required.
Needs and capabilities are not mechanisms in the SOA Reference Architecture. They are the guiding principles for building and using a particular SOA. Nonetheless, the usefulness of a particular SOA depends on how well the needs and capabilities are defined, understood, and satisfied.
Architecture principles define the underlying general rules and guidelines for the use and deployment of all IT resources and assets across the enterprise. They reflect a level of consensus among the various elements of the enterprise, and form the basis for making future IT decisions.
Guiding principles define the ground rules for development, maintenance, and usage of the SOA. Specific principles for architecture design or service definition, are derived from these guiding principles, focusing on specific themes. These principles are the characteristics that provide the intrinsic behaviour for the style of design.
SOA principles should be clearly related back to the business objectives and key architecture drivers. They will be constructed on the same mode as TOGAF 9.1 principles with the use of statement, rationale and implications. Below examples of the types of services which may be created:
· Put the computing near the data
· Services are technology neutral
· Services are consumable
· Services are autonomous
· Services share a formal contract
· Services are loosely coupled
· Services abstract underlying logic
· Services are reusable
· Services are composable
· Services are stateless
· Services are discoverable
· Location Transparency
· Etc.
Here is a detailed principle example:
· Service invocation
o All service invocations between application silos will be exposed through the Enterprise Service Bus (ESB)
o The only exception to this principle will be when the service meets all the following criteria:
§ It will be used only within the same application silo
§ There is no potential right now or in the near future for re-use of this service
§ The service has already been right-sized
§ The Review Team has approved the exception
As previously indicated, the Center of Excellence would also have to provide guidelines on SOA processes and related technologies. This may include:
· Service analysis (Enterprise Architecture, BPM, OO, requirements and models, UDDI Model)
· Service design (SOAD, specification, Discovery Process, Taxonomy)
· Service provisioning (SPML, contracts, SLA)
· Service implementation development (BPEL, SOAIF)
· Service assembly and integration (JBI, ESB)
· Service testing
· Service deployment (the software on the network)
· Service discovery (UDDI, WSIL, registry)
· Service publishing (SLA, security, certificates, classification, location, UDDI, etc.)
· Service consumption (WSDL, BPEL)
· Service execution (WSDM)
· Service versioning (UDDI, WSDL)
· Service Management and monitoring
· Service operation
· Programming, granularity and abstraction
· Etc.
Other activities may be considered by the Center of Excellence such as providing a collaboration platform, asset management (service are just another type of assets), compliance with standards and best practices, use of guidelines, etc. These activities could also be supported by an Enterprise Architecture team.
As described in TOGAF 9.1, the Center of Excellence can act as the governance body for SOA implementation, work with the Enterprise Architecture team, overseeing what goes into a new architecture that the organization is creating and ensuring that the architecture will meet the current and future needs of the organization.
The Center of Excellence provides expanded opportunities for organizations to leverage and re-use service oriented infrastructure and knowledgebase to facilitate the implementation of cost-effective and timely SOA based solutions.
The primary structuring element for SOA applications is a service as distinct from subsystems, systems, or components. A service is an autonomous and discoverable software resource which has a well defined service description.
SOA is based on a fundamental architectural model that defines an interaction model between three primary parties, the service provider, who publishes a service description and provides the implementation for the service, a service consumer, who can either use the uniform resource identifier (URI) for the service description directly or can find the service description in a service registry and bind and invoke the service. The service broker is the third party who provides and maintains the service registry in addition to providing mediation services between providers and consumers.
In 2012, the use of SOA for pivotal emerging technologies, especially for mobile applications and cloud computing, suggests that the future prospect for SOA is favourable. SOA and cloud will begin to fade as differentiating terms because it will just be “the way we do things”. We’re now at the point where everything we deploy is done in a service-oriented way, and cloud is being simply accepted as the delivery platform for applications and services. Also many enterprise architects are wondering if the mobile business model will drive SOA technologies in a new direction. Meanwhile, a close look at mobile application integration today tells us that pressing mobile trends will prompt IT and business leaders to ensure mobile-friendly infrastructure.
To be successful in implementing a SOA initiative, it is highly recommended that a company create a Center of Excellence and the Open Group clearly explains how this can be achieved through the use of TOGAF 9.1. This article is based on the specification and specifically the section (in italics) 22.7.1.3 Partitions and Centers of Excellence with some additional thoughts on sections 22.7.1.1 Principle of Service-Orientation and 22.7.1.2 Governance and Support Strategy.
I have looked at the various attributes and provided further explanations or referred to previous experiences based on existing CoEs or sometimes called Integration Competency Centers.
The figure below illustrates below a SOA Center of Excellence as part of the Enterprise Architecture team with domain and solution architects as well as developers, QAs and business architects and analysts coming from a delivery organization.
This center of excellence support methodologies, standards, governance processes and manage a service registry. The main goal of this core group is to establish best practices at design time to maximize reusability of services.
Below is then what is written in the TOGAF 9.1 specification.
A successful CoE will have several key attributes:
Any SOA Center of Excellence must have a purpose. What do we want to achieve? What are the problems we need to solve?
It may sound obvious, but having a blueprint for SOA is critical. It’s very easy for companies, especially large enterprises with disparate operations, to buy new technologies or integrate applications without regard to how they fit into the overall plan. The challenge in building a SOA is to keep people, including IT and business-side staff focused on the Enterprise Architecture goals.
In order to realize the vision of SOA the following topics should be addressed:
· What to build: A Reference Architecture
· How to build: Service-Oriented Modeling Method
· Whether to build: Assessments, roadmaps, and Maturity evaluations
· Guidance on Building: Architectural and Design patterns
· Oversight: Governance
· How to build: Standards and Tools
The Center of Excellence would first have a vision which could be something like:
“ABCCompany will effectively utilize SOA in order to achieve organizational flexibility and improve responsiveness to our customers”.
Then a mission statement should be communicated across the organization. Below a few examples of mission statements:
“To enable dynamic linkage among application capabilities in a manner that facilitates business effectiveness, maintainability, customer satisfaction, rapid deployment, reuse, performance and successful implementation.”
“The mission of the COE for SOA at ABCCompany is to promote, adopt, support the development and usage of ABCCompany standards, best practices, technologies and knowledge in the field of SOA and have a key role in the business transformation of ABCCompany. The COE will collaborate with the business to create an agile organization, which in turn will facilitate ABCCompany to accelerate the creation of new products and services for the markets, better serve its customers, and better collaborate with partners and vendors.”
The Center of Excellence would also define a structure and the various interactions with
· the enterprise architecture team
· the project management office
· the business process/planning & strategy group
· the product management group
· etc.
And create a steering committee or board (which could be associated to an architecture board).
They will provide different types of support:
· Architecture decision support
o Maintain standards, templates and policies surrounding Integration and SOA
o Participate in Integration and SOA design decisions
· Operational support
o Responsible for building and maintaining SOA Infrastructure
o Purchasing registries and products to grow infrastructure
· Development support
o Development of administrative packages and services
o Develop enterprise services based on strategic direction
Measurements and metrics will have to be identified. The common ones could be:
· Service revenue
· Service vitality
· Ratio between services used and those created
· Mean Time To Service Development or Service change
· Service availability
· Service reuse
· Quality assurance
· Etc.
Clearly comprehensive testing activities must be described by the Center of Excellence. In addition to a set of defined processes related to Web Service Definition Language (WSDL) testing, functional unit testing, regression testing, security testing, interoperability testing, vulnerability testing and load, performance testing, an analysis tool suite may be used to tailor the unique testing and validation needs of Service Oriented Architectures.
This helps test the message layer functionality of their services by automating their testing and supports numerous transport protocols including: (here a few examples) HTTP 1.0, HTTP/1.1, JMS, MQ, RMI, SMTP, .NET WCF HTTP, .NET WCF TCP, Electronic Data Interchange, ESBs, etc.
Only by adopting a comprehensive testing stance, enterprises can ensure that their SOA is robust, scalable, interoperable, and secure.
The Center of Excellence will promote best practices, methodologies, knowledge, and pragmatic leading-edge solutions in the area of SOA to the project teams.
This may sounds like a good idea but I have never seen this as an applied practice.
Competency and skills building is needed for any initiative. SOA is not just about integrating technologies and applications but it is a culture change within the enterprise which requires IT to move from being a technology provider to a business enabler. There may be a wide range of skills required such as:
· Enterprise Architecture
· Value of SOA
· Governance model for SOA
· Business Process Management and SOA
· Design of SOA solutions
· Modeling
· Technologies and standards
· Security
· Business communication
· Etc.
It has to be said that lack of SOA skills is the number one inhibitor to SOA adoption.
Here again, I am not sure that I have observed any Center of Excellence being closed…
The Center of Excellence will then also define a Reference Architecture for the organization.
A Reference Architecture is an abstract realization of an architectural model showing how an architectural solution can be built while omitting any reference to specific concrete technologies. Reference Architecture is like an abstract machine. It is built to realize some function and it, in turn, relies on a set of underlying components and capabilities that must be present for it to perform. The capabilities are normally captured into layers which in their own right require an architectural definition. However, the specific choice of the components representing the capabilities is made after various business and feasibility analysis are performed. A Reference Architecture can be used to guide the realization of implementations where specific properties are desired of the concrete system.
The purpose of the Reference Architecture is reflected in the set of requirements that the Reference Architecture must satisfy. We can structure these requirements into a set of goals, a set of critical success factors associated with these goals and a set of requirements that are connected to the critical success factors that ensure their satisfaction.
A Reference Architecture for SOA describes how to build systems according to the principles of SOA. These principles direct IT professionals to design, implement, and deploy information systems from components (i.e. services) that implement discrete business functions. These services can be distributed across geographic and organizational boundaries, can be independently scaled and can be reconfigured into new business processes as needed. This flexibility provides a range of benefits for both IT and business organizations.
Using the pattern approach the SOA Reference Architecture is a means for generating other more specific reference architectures, or even concrete architectures depending on the nature of the patterns. Or to put it another way, it is a machine for generating other machines.
The Open Group Standard for SOA Reference Architecture (SOA RA) is a good way of considering how to build systems.
The center of Excellence needs also to define the SOA life cycle management which consists of various activities such as governing, modelling, assembling, deploying and controlling/monitoring.
Simply put, without management and control, there is no SOA only an “Experience”. The SOA infrastructure must be managed in accordance with the goals and policies of the organization, which include hardware and software IT resource utilization, performance standards as well as goals for service level objectives (SLOs) for the services provided to IT users as well as business goals and policies for businesses that run and use IT. To be truly agile, enactment of all these different types of policies requires automated control that allows goals to be met with only the prescribed level of human interaction.
For every layer of the SOA infrastructure a corresponding Manage and Control component needs to exist / be in place. Moreover, the “manage and control” components must be integrated in a way that they can provide an end-to-end view of the entire SOA infrastructure.
These manage and control functions provide the run-time management and control of the entire enterprise IT execution environment. This includes all of the enterprise’s business processes and information services, including those associated with the IT organization’s own business processes.
The “Principle of Service orientation” must exist as defined in 22.7.1.1 Principle of Service-Orientation, but lower levels of principles, rules, and guidelines are required.
Needs and capabilities are not mechanisms in the SOA Reference Architecture. They are the guiding principles for building and using a particular SOA. Nonetheless, the usefulness of a particular SOA depends on how well the needs and capabilities are defined, understood, and satisfied.
Architecture principles define the underlying general rules and guidelines for the use and deployment of all IT resources and assets across the enterprise. They reflect a level of consensus among the various elements of the enterprise, and form the basis for making future IT decisions.
Guiding principles define the ground rules for development, maintenance, and usage of the SOA. Specific principles for architecture design or service definition, are derived from these guiding principles, focusing on specific themes. These principles are the characteristics that provide the intrinsic behaviour for the style of design.
SOA principles should be clearly related back to the business objectives and key architecture drivers. They will be constructed on the same mode as TOGAF 9.1 principles with the use of statement, rationale and implications. Below examples of the types of services which may be created:
· Put the computing near the data
· Services are technology neutral
· Services are consumable
· Services are autonomous
· Services share a formal contract
· Services are loosely coupled
· Services abstract underlying logic
· Services are reusable
· Services are composable
· Services are stateless
· Services are discoverable
· Location Transparency
· Etc.
Here is a detailed principle example:
· Service invocation
o All service invocations between application silos will be exposed through the Enterprise Service Bus (ESB)
o The only exception to this principle will be when the service meets all the following criteria:
§ It will be used only within the same application silo
§ There is no potential right now or in the near future for re-use of this service
§ The service has already been right-sized
§ The Review Team has approved the exception
As previously indicated, the Center of Excellence would also have to provide guidelines on SOA processes and related technologies. This may include:
· Service analysis (Enterprise Architecture, BPM, OO, requirements and models, UDDI Model)
· Service design (SOAD, specification, Discovery Process, Taxonomy)
· Service provisioning (SPML, contracts, SLA)
· Service implementation development (BPEL, SOAIF)
· Service assembly and integration (JBI, ESB)
· Service testing
· Service deployment (the software on the network)
· Service discovery (UDDI, WSIL, registry)
· Service publishing (SLA, security, certificates, classification, location, UDDI, etc.)
· Service consumption (WSDL, BPEL)
· Service execution (WSDM)
· Service versioning (UDDI, WSDL)
· Service Management and monitoring
· Service operation
· Programming, granularity and abstraction
· Etc.
Other activities may be considered by the Center of Excellence such as providing a collaboration platform, asset management (service are just another type of assets), compliance with standards and best practices, use of guidelines, etc. These activities could also be supported by an Enterprise Architecture team.
As described in TOGAF 9.1, the Center of Excellence can act as the governance body for SOA implementation, work with the Enterprise Architecture team, overseeing what goes into a new architecture that the organization is creating and ensuring that the architecture will meet the current and future needs of the organization.
The Center of Excellence provides expanded opportunities for organizations to leverage and re-use service oriented infrastructure and knowledgebase to facilitate the implementation of cost-effective and timely SOA based solutions.
These days, it seems that business and IT conversations just about everywhere are revolving around that same 4 themes – Big Data, social collaboration, mobile applications and cloud computing. These IT megatrends are in the forefront of the minds of IT executives and solution providers alike. And, if you aren’t thinking about them, you should […]
Related posts:
Related posts brought to you by Yet Another Related Posts Plugin.
Understanding how to handle customer needs and expectations is critical to success. From better service levels to lower costs to new, innovative product offerings, the pressure is on for organizations to go above and beyond. And, as consumerization continues its exponential growth, organizations need to find better ways to meet the ever-changing demands of their […]
Related posts:
Related posts brought to you by Yet Another Related Posts Plugin.
How important is the human factor in driving meaningful process improvements for your business? I believe it is THE most important, and arguably the most difficult, aspect of any effort to improve performance. I recently participated in an educational virtual summit aptly titled ACMLive that considers what it takes to properly support human knowledge work. […]
Related posts:
Related posts brought to you by Yet Another Related Posts Plugin.
Loan processes are complex. From loan origination to underwriting to closing, there are many moving parts for each application, creating unwanted and unnecessary bottlenecks along the way. Earlier this year we formally surveyed banking executives from across North America to help us better understand the pitfalls within loan processing. One of the most surprising results […]
Related posts:
Related posts brought to you by Yet Another Related Posts Plugin.