Gabriel Morgan : Enterprise Architecture Concepts

Service Delivery Platform (SDP) for the Enterprise

Gabriel Morgan — Sat, 29 Sep 2007 03:15:00 GMT

I'm noticing a lot of great improvements in Enterprise Architecture Frameworks, namely FEAF, TOGAF, Gartner EAF and ITIL (Yes, I see ITIL as an EAF now). They are embracing similar improvement themes like Business Strategy linkage, enabling agile business via Service-Oriented Architecture approaches, iterative delivery processes, federated team models, and process, information and system complexity reduction.

The good news is that they are learning. And the bad news, unfortunately, is that they are learning and each new concept they gradually expand and adopt takes a bit of catch-up with what industry thought-leaders already know and it takes time to get new ideas incorporated into EAF documention.

For those of us who have to sign-up and deliver to our CxO executives useful architectures usually anchor, somewhat loosely, to one of the popular EAFs out there and then liberally pull from the best practices that we discover. I'd like to highlight a best practice from a somewhat lesser known EAF called New Generation Operations Support Services (NGOSS) that may radically impact the way your EAF implementation looks today. The best practice is the notion of a Service Delivery Platform (SDP) from the telecommunications industry.

We all know that SOA is a powerful tool to enable an agile business but we don't know what the nuts and bolts, bits and bobs of the resulting well-formed business process, information and system architectures are if we use your typical SOA approach. Well, it turns out that the telecom industry has largely solved this and are working on the challenges of what comes next.

Huh? Am I saying that there's more work to improve our architecture after we get a first serious rev of architecture based on SOA? Yes, there is! Through continuous improvement and change in the business, we will continually modify our architecture to advance our business and be more competitive.

For example, based on the needs of faster delivery of services, there are higher levels of sophistication in how to do Service Management with features like Service Naming, Registry and Location Services, Service Policy Management, Service Quality Management, Service Configuration Management, and Service Rating and Discounting Management.

Another example, is the sophistications in how an enterprise will handle supporting shared services. Enterprise Architectures will need to support shared services and will require sophistications in Dev and Test environments, Governance process and team models, SDLC modifications, Customer Support and Service Consultation/On-boarding.

And finally, there are levels of sophistication how the enterprise architecture will look in S+S scenarios such as process, information and system integration with cloud services. Or, resolve how the architecture will handle partner collaboration and customer-centric challenges the business strive for.

Some may argue that these are already included in a SOA approach - these people are thought leaders and are very rare. For the rest, these bits of sophistication aren't even on the radar yet.

The point is that they definitely are involved and most mainstream SOA approaches out there today don't know this yet. The NGOSS framework is focused on these aspects and through the competitive, free market forces in the telecom industry, they are improving on their framework relatively rapidly. In fact, I predict that enterprises will begin to adopt them and we will see more and more of the SDP concepts built into enterprise products moving forward.

I suggest you take a look at the NGOSS and eTOM documents produced by the TeleManagement organization. Here's their website. Register for free and then start looking at the free material. Pay particular attention to the Enhanced Telecom Operations Map (eTOM), Technology Application Map (see image below), Technology-Neutral Architecture models and Shared Information Data (SID) model that make up the NGOSS EAF.

Of course, NGOSS is more geared to delivery of monetized services than support of an enterprise shared services. But the capabilities they have created to solve for service delivery in a Service Delivery Platform are relevant for the enterprise.

That's my main point of this blog post. I see value in NGOSS/eTOM as a catalyst for improvement in an Enterprise Architecture via, at the very least, a mature Service Delivery Platform to realize SOA. Hence, SDP for the Enterprise.

As it turns out, Microsoft has a strong competency in the SDP space and have a product named Connected Systems Framework (CSF) which is born from the telco industry but generic enough to support an enterprise. Here's more info on CSF: http://msdn2.Microsoft.com/en-us/library/aa445859.

Here's a rough CSF technical architecture diagram to help convey some of the components included in the CSF solution.

Also, have a look at the article "Efficient Software Delivery Through Service-Delivery Platforms" by Gianpaolo Carraro, Fred Chong, and Eugenio Pace found here: http://msdn2.microsoft.com/en-us/architecture/bb735303.aspx

Now, for enterprises seeking to offer Services in a S+S business model, there is much more here to leverage. More on this later.

The formula for Agility

Gabriel Morgan — Fri, 07 Sep 2007 04:59:00 GMT

Months ago I published a blog about how to implement system quality attributes (found here). In that article I asserted that Solution Architects should deliberately design systems for high quality and I provided a means for doing this. Because the point of software, or so I assert, is to automate business processes and protect data quality with the goal of enabling an Agile business, I'd like to propose a formula for determining System Agility.

So, how can we design systems to optimize System Agility in order to enable our agile business? Perhaps this isn't all that complicated if we use system quality attributes. Here's a stab at a formula for System Agility:

A=2(F)+M+I+T+R-P-S

The aim of this formula is not to pretend that one could use it to calculate System Agility with precision. Rather it is more of an attempt to describe how System Agility could be achieved. Using the formula allows me to describe the relationship of key system quality attributes that optimize and degrade System Agility and leave it to the Solution Architect to focus on the relative system quality attributes and implement systems design to optimize or minimize each of the key system quality attributes included in the formula.

Before I explain each factor, let me cover the assumptions I've made:

Agile businesses require Agile systems and the definition I use for System Agility is the ability of a system to be both flexible and undergo change rapidly [MIT ESD 2001].
The list of system quality attributes listed at the end of this blog under the label System Quality Attribute Definitions is the finite set of system quality attributes. Yes, I know that this is a false assumption but humor me for a moment.
I don't get into the complications of the natural system quality dependencies. That is, for the sake of this formula being very simple, I don't recognize the dependency tree of system quality attributes and their interrelationships and I let each system quality attribute stand on it's own.
For simplicity of my key messages in this blog, I focus on the software system only and don't address organizational capabilities nor infrastructure needed to properly deliver System Agility to an enterprise.

Let me take a moment and explain each factor in the equation.

(F) System Flexibility Factor. The most important system quality attribute to enable System Agility is System Flexibility. System Flexibility enables systems to be used in different ways and to be modified for these different uses. It is the means for decoupling interactions between actors. Targeting System Agility, System Flexibility allows software to be reused in ways not thought of at the time of development. I published a blog on System Flexibility, found here, that directly addresses ways to optimize System Flexibility at the enterprise-level. For this reason, I've assigned a multiplication factor to System Flexibility to emphasize the importance of System Flexibility to System Agility.

(M) System Maintainability Factor. System Maintainability is very important to agile software. The key here is code that is optimized for System Maintainability is more likely to withstand changes from bugs that are found and fixed or as well as software that undergoes natural improvements. Software characteristics that are directly pertinent to System Maintainability include; Versioning, Re-factored code, Code Complexity, code structure, etc.

(I) System Interoperability Factor. System Interoperability brings to the table a focus on interoperating between systems, which is arguable one of the most important concerns for enterprise applications system integration. Software characteristics that are directly pertinent to System Interoperability include; Service Operation designed for uniqueness and extensibility, Message Schemas including those that are canonical, software design patterns that optimize for composability to support orchestration and workflow.

(T) System Testability Factor. System Testability is important because it forces system designers to make deliberate system architecture decisions to ensure that the software that is produced can be easily tested for delivery. Especially as we see software designed from service-oriented software architecture approaches and S+S needs, the ability to design software to enable these types of software needs requires intentional design to optimize testability. Software characteristics that are directly pertinent to System Testability include; abilities to perform Unit Tests, Customer Tests, Stress Test, Exception Tests, Failover Tests, Function Tests, Security Penetration Tests, Performance Test, System Integration Tests, Regression Tests, Code Coverage Tests, etc.

(R) System Reusability Factor. System Reusability is an important system quality attribute involves major architectural styles and patterns like the Service Layer Pattern [Fowler 2003], basic software design principles such as software encapsulation and the familiar SOA Tenets.

(P) System Performance Factor. System Performance often degrades System Agility and for this reason I've asserted that System Performance subtracts from the previously noted system quality attribute factors. Bummer. I wish that we could have our cake and eat it too but the reality is that when optimizing for System Agility, System Performance is a Tradeoff Point. For example, often the fastest systems tend to consolidate large amounts of logic, data and processing instructions onto a single platform to reduce network latency, packaging and unpackaging of inter-process information, data access, etc. I don't want to ignore performance enhancing techniques such as caching and patterns such as Data Transfer Object [Fowler 2003]. These are great ways to lessen the impact that System Performance can place on System Agility. It's just that these add a bit of complexity to the rest of the system and can degrade System Maintainability and System Testability for example and still don't, from a purist perspective, optimize System Performance.

(S) System Security Factor. Like System Performance, System Security often degrades System Agility and for this reason I've asserted that System Security has a negative relationship to the equation. For example, Adding software characteristics such as role-based security into a system at the data layer, application layer, host layer and network layer adds significant degradation to System Performance, System Testability and System Maintainability. I'm not at all suggesting that a Solution Architect should read this as a suggestion to place little System Security design into their system. The trick, as a colleague once told me, is to have just enough security.

System Quality Attribute Definitions

Agility

Agility is the ability of a system to be both flexible and undergo change rapidly. (MIT ESD 2001)

Flexibility

Flexibility is the ease with which a system or component can be modified for use in applications or environments other than those for which it was specifically designed. (Barbacci 1995)

Maintainability

Maintainability is:

· The aptitude of a system to undergo repair and evolution. (Barbacci 2003)

· The ease with which a software system or component can be modified to correct faults, improve performance or other attributes, or adapt to a changed environment. (2) The ease with which a hardware system or component can be retained in, or restored to, a state in which it can perform its required functions. (IEEE Std. 610.12)

Interoperability

Interoperability is the ability of two or more systems or components to exchange information and to use the information that has been exchanged. (IEEE 1990)

Testability

Testability is the degree to which a system or component facilitates the establishment of test criteria and the performance of tests to determine whether those criteria have been met (IEEE 1990).

Reusability

Reusability is the degree to which a software module or other work product can be used in more than one computing program or software system. (IEEE 1990).

This is typically in the form reusing software that is an encapsulated unit of functionality.

Performance

Performance is the responsiveness of the system – the time required to respond to stimuli (events) or the number of events processed in some interval of time. Performance qualities are often expressed by the number of transactions per unit time or by the amount of time it takes to complete a transaction with the system. (Bass 1998)

Security

Security is a measure of the system’s ability to resist unauthorized attempts at usage and denial of service while still providing its services to legitimate users. Security is categorized in terms of the types of threats that might be made to the system. (Bass 1998)

Reliability

Reliability is the ability of the system to keep operating over time. Reliability is usually measured by mean time to failure. (Bass 1998)

Supportability

Supportability is the ease with which a software system is operationally maintained.

Performance

Security

Scalability

Scalability is the ability to maintain or improve performance while system demand increases.

Usability

Usability is:

· The measure of a user’s ability to utilize a system effectively. (Clements 2002)

· The ease with which a user can learn to operate, prepare inputs for, and interpret outputs of a system or component. (IEEE Std. 610.12)

· A measure of how well users can take advantage of some system functionality. Usability is different from utility, a measure of whether that functionality does what is needed. (Barbacci 2003)

Sources

· [Bachmann 2000] Bachmann, F.; Bass, L.; Chastek, G.; Donohoe, P. & Peruzzi, F. The Architecture Based Design Method (CMU/SEI-2000-TR-001 ADA375851). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2000. Available WWW: <URL: http://www.sei.cmu.edu/publications/documents/00.reports/00tr001.html>.

· [Barbacci 1995] Barbacci, M.; Klien, M.; Longstaff, T; Weinstock, C. Quality Attributes - Technical Report CMU/SEI-95-TR-021 ESC-TR-95-021. Carnegie Mellon Software Engineering Institute, Pittsburgh, PA.

· [Barbacci 2003] Barbacci, M. Software Quality Attributes and Architecture Tradeoffs. Software Engineering Institute, Carnegie Mellon University. Pittsburgh, PA.

· [Bass 1998] Bass, L.; Clements, P.; & Kazman, R. Software Architecture in Practice. Reading, MA; Addison-Wesley.

· [Bass Kazmann 1999] Bass, L.; Clements, P.; & Kazman, R. Architecture-Based Development.

· [Fowler 2003] Martin Fowler. Patterns of Enterprise Application Architecture, Boston, MA. Addison-Wesley.

· [Gamma 1995] Gamma, E.; Helm, R; Johnson, R.; & Vlissides, J. Design Patterns, Elements of Reusable Object-Oriented Software. Addison-Wesley. Carnegie Mellon Software Engineering Institute

· [Hohpe Woolf 2004] Gregor Hohpe and Bobby Woolf. Enterprise Integration Patterns. Boston, MA. Addison-Wesley.

· [IEEE 1990] Institute of Electrical and Electronics Engineers. IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York, NY.

· [IEEE 1992] IEEE Std 1061-1992: IEEE Standard for a Software Quality Metrics Methodology. Los Alamitos, CA: IEEE Computer Society Press.

· [Kazman 2000] Kazman, R.; Klein, M. & Clements, P. ATAM: Method for Architecture Evaluation CMU/SEI-2000-TR-004 ADA382629. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University. Available WWW: <URL: http://www.sei.cmu.edu/publications/documents/00.reports/00tr004.html>

· [MIT ESD 2001] Tom Allen, Don McGowan, Joel Moses, Chris Magee, Dan Hastings, Fred Moavenzadeh, Seth Lloyd, Debbie Nightingale, John Little, Dan Roos, Dan Whitney. ESD Terms and Definitions (Version 12); Massachusetts Institute of Technology. Engineering Systems Division. ESD-WP-2002-01, October.

How SaaS, S+S impact an Enterprise Architect

Gabriel Morgan — Thu, 30 Aug 2007 07:39:00 GMT

Mike Walker wrote a great thought-provoking blog post on the implications SaaS has on Enterprise Architecture. Although he noted some very interesting points, I thought I’d extend this a bit and describe the impact of my life as it pertains to SaaS because coincidentally, I'm an Enterprise Architect and am personally tasked in an initiative to help solve how Microsoft IT is involved with SaaS. So, I'm in the throes of the interesting implications of how I do my job as I address this challenge.

I posted some of the thoughts on how I address business analysis as part of defining the Business Architecture. I break up the problem space into two very different areas: Business Analysis for Consuming SaaS and Business Analysis for Providing SaaS. Here are the blogs respectively.

· http://blogs.msdn.com/gabriel_morgan/archive/2007/07/18/business-analysis-for-consuming-saas-services.aspx

· http://blogs.msdn.com/gabriel_morgan/archive/2007/07/18/business-analysis-for-providing-saas-services.aspx

Because I'm short on time let me blurt out some comments in the area of "EA implications for consuming SaaS software":

The distinction between business capability and applications is very important. This will get clearer as I describe the Business Architecture implications below. Btw, I wrote a blog about these concepts to put them in an information model view to help describe how they relate. See here http://blogs.msdn.com/gabriel_morgan/archive/2007/07/31/traceability-from-biz-strategy-to-application.aspx.
Application Portfolio Management is still in the picture. Although the SaaS service means that the software and infrastructure is in the cloud, they are still a part of our application portfolio and must be rationalized to avoid redundancy and managed to ensure we make informed decisions how to position it over time.
With regard to the Business Architecture domain, things get interesting with consuming SaaS services because:

There needs to be attention paid on consuming SaaS services which are ‘Supporting’ business capabilities rather than focusing on those business capabilities which are ‘Core’ to a business. Why only the Supporting business capabilities? Well, because we don’t want to be locked into the dangers of our businesses struggling to be innovative and agile with their business process and them being constrained by a SaaS software that automate them. Remember, that the majority of SaaS provider software out there is built to be supported by several companies simultaneously using the same code base.
There needs to be attention paid to the 'connectdness' of business capabilities and look for business capabilities that are relatively independent of one another. That is, look for business capabilities that have relatively little dependency on other business capabilities especially as it pertains to business process and information.
Business process integration. We need to still model the SaaS software in relation to business processes to ensure we are optimizing the value of the SaaS software investment.

With regard to System Architecture domain, things get interesting:

When desigin system integration for both business process workflows as well as the data integration needs via system-to-system data integration. There are some interesting innovations happening in this space as system and data integration themselves can be SaaS services but I digress. Anyway, think of the challenges of supporting systems in your local IT shop that must, and I repeat, must integrate with services in the cloud. Such challenges and being responsible for the Quality of Services requirements your business has as it relates to their system, which they may not even be aware depends on clous services, such as system reliability, system maintainability, system supportability, and system testability. Yes, these issues fall on the shoulders of the local IT shop and they are not simple to solve. In our experience, which is quite young, requires an astonishing close relationship with our SaaS providers to the point that sometimes it looks like they are merely an extension of our IT shop. I'm sure that this will change as SaaS providers and the consumers (aka us) work out the kinks of working better together and streamline the basic delivery activities but for now, we are still learning.
Presentation mash-ups. As an EA, we love the concept of the business being able to build their own applications using readily available software services via presenation applications and workflows. Nick wrote more about this on this blog entry so I won't cover it here. The point I want to make is that we promote those SaaS services which enable this type of situation.

With regard to Information Architecture domain:

Like Mike noted, attention must be paid to the information that can legally be stored in the cloud. Think financial information in Europe. This is not always legal for this type of information to leave the country.
Data integration needs are very important. We are very weary of storing data in the cloud if we have Quality of Service requirements such as Data Staleness of less than 1 hour (or thereabouts). This is just an observation and probably a result of a lack of maturity of system integration abilities and think that we will overcome this in due time.
Data Masters are left on-premise at the moment. We are very weary of storing master data outside of our control. In fact, I'm not aware of any such situation. Instead, I'm seeing more interest in SaaS software that stores anciliary or extended information that is readily retrievable to a master data store.

In short, SaaS provides a lot of potential cost savings that are of high interest BUT they do bring with them some interesting challenges to an Enterprise Architect to make sure that SaaS sofware is optimized for the business investment.

Enterprise Architecture Mapping Artifacts - They are very powerful so be very, very careful

Gabriel Morgan — Fri, 17 Aug 2007 02:51:00 GMT

I wrote a blog (found here) describing the relationship from Business Strategy to other Business Architecture concepts and several IT concepts. I also introduced a few new concepts to the traditional view; Business Capabilities, Solution Domains and Data Facets that are fundamental to manage larger enterprise organizations. I’d like to reference that blog and the definitions of the concepts to talk now about how these concepts are used in portfolio mapping artifacts and share with you things that I’ve learned.

The following mappings list is by no means complete. My intention is to start a list and fill it in as I learn more. My intention is to bring awareness of mappings that I've observied having proved useful, mappings that have been less successful and throw in some related risks and assumptions as a way of added education to keep in mind when considering a particular mapping artifact.

One overlaying learning to all of these mappings I’d like to stress “Know what you are doing and clearly understand the goal". Compromises will innevitably happen so remember to avoid being distracted with the realities of the data you must work with. It is easy to lose sight of the goal and end up making compromises because one of the mapping concepts isn’t entirely there or is poorly defined or is inconsistent, etc - you might end up with an artifact labeled correctly but containing data that is totally useless to addressing the goal. Know the risks and assumptions associated with a mapping so that you can make wise decisions what to do with it and how to communicate it so that it isn't misinterpreted downstream.

As always, feedback is very welcome.

Mappings		Value from the mapping	Risks	Assumptions
1	Business Strategy to Business Capability	· Know what major buisness functions are needed to deliver on the Business Strategy. · Manage major KPIs tied to Business Capabilities that will delivery on the Business Strategy.	· Lose sight of important business functions that perform average or relatively well b/c usually Business Capability maps tend to draw the reader’s focus on the poorly performing Business Capabilities.	· Business Capabilities represent all Business Objectives. There are times when Business Objectives are spread between several Business Capabilities and Business Capability abstraction levels.
2	Business Capabilities to Business Processes	· Know what process traverse Business Capabilities, therefore 'connecting' Business Capabilities. This allows for planning of what Business Capabilities are improved when Business Processes improve. · Know what 'major' Business Processes to investigate for improvement to improve a Business Capability.
3	Business Process to Solution Domains	· Simplified business systems view based on Business Process activities. · Simplified standard business system interfaces for 'macro' Software Service and subsequently Application reuse. · Application models are largely defined.	· Lose sight of business system stability because Business Processes change frequently and there is a looser tie to the more stable business views via Business Capability models.	· Business Processes are rationalized. · Business Process Activities are relatively stable.
4	Solution Domains to Applications	· Simplified business system portfolio. · Simplified data/information architecture, Application architecture/design guidance and policies.	· Lose sight of Technology Capabilities and therefore sub-system/non-functional Applications are not rationalized.	· Application functionality/features clearly map to Solution Domains.
5	Business Capabilities to Applications	· A view of what Business Capabilities use software and which ones don't. · A list of business application features which support one or more Business Capabilities.	· False indicator of application redundancy. · Although Business Capabilities contribute to rationalizaing Business Processes there is a risk of it being a false indicator of Business Process redundancy. · Difficult to quantify the portion of an Application for how it contributes to a Business Capability.	· Confuse Business Capabilities as reflecting Software Services. · Confuse Business Capabilities as reflecting Business Processes. · All Business Capabilities require software. · Business Capabilities represent business needs or 'features'.
6	Business Process to Applications	· A view of what Business Processes have supporting Applications and which do not	· False indicator of redundant Software Services based on Business Process Activities. · Lose sight of the importance of business information.	· All Busienss Process Activities reflect software services. · Naming and granularity of Business Processes are rationalized across the enterprise.
7	Technology Capabilities to Applications	· Simplified product-agnostic technology portfolio.	· Confusion for what capabilities Applications or technologies provide or consume (primary or secondary).

Traceability from Biz Strategy to Application to Data to Hardware...

Gabriel Morgan — Wed, 01 Aug 2007 01:28:00 GMT

Recently, I’ve had a number of conversations with folks regarding concepts at the enterprise-level mostly focused on traceability from some architecture concept to Business Strategy. After all, if someone asserts an architecture concept and it isn’t traceable to a Business Strategy there is a natural reflex to question its purpose.

Here’s a view of a simple model illustrating the relationship between major enterprise concepts.

Let me describe each model element to make the model more clear:

· Business Strategy. This is the actual stated buisness direction that a company declares with the purpose of providing directional statements with measurable goals to its organization.

o Purpose: Statement of business direction

o Example: ‘Increase revenue in enterprise customer accounts by delivering large, industry vertical solutions by 10% in FY08’

· Business Process. The collection of interrelated tasks that solve a particular issue.

o Purpose: Manage how the business executes.

o Example: Process Invoice, Assign Resource, Create Offering, Sell Offering

· Application. An application is a software asset.

o Purpose: Physical software which contributes directly or indirectly to automating a business process.

o Example: Sharepoint, Excel, COTS Pacakge xyz, Custom-Roll-your-own system abc.

· Data. Disorganized unstructured, structured or semi-structured information.

o Purpose: What is stored by business processes and used to make business decisions.

o Example: Customer address street name, Packaged offering SKU abcdef item description, image file

· Hardware. Infrastructure of interconnected devices which host IT systems.

o simplePurpose. Physical computer hardware which host IT systems.

o Example: Server, switch, desktop, cables.

Being intimately familiar with these concepts is important for simplification, control or any other worthy endeaver to deliver value to your company.

Unfortunately, for large organizations these concepts are too detailed to manage and there is a need to abstract them while maintaining exclusivity between them - especially management of the business applications.

For purposes of brevity, I’m not going to talk about Asset Lifecycle Management or Application Portfolio Management specifically. The concepts I’ll introduce next are certainly related and complimentary to ALM and APM but do not cover them in their entirety.

For large organizations managing business systems I have to introduce a few more concepts to the picture; Business Capability, Solution Domain and Data Facet. The picture below illustrates these three concepts as addition model elements into the same view as above to help describe them in context.

· Business Capability. A business capability is a business function encapsulating people, process, technology and data.

o Purpose: Manage the major business functions of an organization to deliver on the Business Strategy

o Example: Resource Planning, Offering Design, Sales Force Administration

· Solution Domain. A Solution Domain is the highest level abstraction of a software system that represents a logical grouping of system functionality which master Data Facets.

o Purpose: Analysis tool to rationalize business software systems and provide guidance for building core business system services for an enterprise.

o Example: Agreement Management, Selling Framework Management, Project Resource Management.

· Data Facet. A Data Facet is a specific aspect, or particular view (among many views) of a subject area; a group of data that describes this aspect.

o Purpose: An abstraction above a Conceptual Information Model or Business Objects and is used to define information across an enterprise.

o Example: Software Product, Customer, Agreement

In the Microsoft IT Enterprise Architecture program, we’ve built out taxonomies for each of these concepts with the purpose of improving our ability to manage our IT assets and ensure their integrity and quality as well as mapping them to Business Strategy.

With them, we have discovered some interesting principles that balance the relationships between the business and IT in very simple models. They are quickly becoming fundamental for our work.

I’d love to hear other ideas for achieving the same goals. Do you use something similar or different?

Top-down, Bottom-up...but what is the 'Middle'?

Gabriel Morgan — Fri, 13 Jul 2007 21:35:00 GMT

There was a recent conversation between several folks on the topic of what Top-down is versus what Bottom-up is. I think of these two terms as analysis approaches similar to the OSI Seven Layer Model which clearly describes what is up and what is down. Using the OSI Seven Layer Model as a metaphor, 'Bottom Up' would be analysis of a enterprise architecture from the physical layer and working your way up to the business strategy/goals and 'Top Down' would be analysis of an enterprise architecture from the Business Strategy/Goals and working your way down to the physical layer. Of course, the OSI Seven Layer Model doesn't aknowledge Business Strategy, but I hope you get my attempt at correlating to the OSI model anyway :).

Although I think that these two concepts are interesting, I feel that they are only a means to an end...and the end being 'The Middle'. If one could define The Middle, we could make a significant step to defining that elusive creature called business to IT alignment, or as a Gartner analyst once said business to IT fusion. I sort of like the twist of using the word fusion because it conotates a tighter relationship between business and IT and feels more like IT adjusting to the business in near-real time. Anyway, with regard to enterprise architecture, The Middle is a standard public system interface of a business software system with a clear intention of optimizing for system flexibility in the system design. The Middle, therefore, must have at least the following characteristics:

Clearly describe software service endpoints which automate a business process step/task/activity
Defines the business information/objects via a canonical message schema passed into (and out of if appropriate) the business system interface
Defines a published address and transport protocol of the software service
Is inclusive of the logical system architecture Service Layer pattern

I'm certain that there are more characteristics and over time I'll update and build upon this list. For now, I'd like to simply assert a few to get the concept out there.

Can there be other 'Middles' such as those software services which have a standard interfaces to data, like the situation that Master Data Management solutions propose, and software services which that support Bridge or Gateway interfaces? Yes, of course! However these are methods for building high-quality software sub-systems to support the business software. So, from the enterprise architecture viewpoint and a focus on fusing the business and IT, The Middle is the business software system interfaces not lower-level standard system interfaces.

So, is The Middle an analysis approach compared to Top-Down and Bottom-Up? No. The Middle is the end game and is a result of analysis combining both Top-Down, Bottom-Up and Middle-out analysis methods. The main point is to know what you are looking for when using these approaches before using them and avoid waisting heaps of time. I would like to note that using Top-Down and Bottom-Up analysis helps with identifying traceability from Business Strategy to physical implementation that will be very useful down the road if/when someone from the business or and IT group needs a simple view for why The Middle is necessary and how it affects them.

'Capability' - the micro-trendy word on its way to failure unless...

Gabriel Morgan — Sat, 31 Mar 2007 20:06:00 GMT

Is it just me or is the word ‘capability’ becoming a micro-trendy word and losing its meaning? I personally liked it b/c I love ways in which to communicate at abstract levels however it is so overloaded these days that I now try to avoid it and find myself cringing when hearing it misused.

In the context of different enterprise architecture, domains like the Business Domain, Application Domain and Technology Domain and at different IT organizational levels like the Senior Execs, Middle Management and project teams the word 'Capability' means entirely different things causes heaps of confusion.

I suppose that the proliferation of the word indicates it has a bit of merit in the right context and it should be used. But at as a result, those who like to spout their knowledge based on no understanding of the subject often misunderstand it and more often than not use it inappropriately. This leads to utter frustration and the need to find another word leaving a bit of damage to the proper use of the word 'capability' that only time will heal. This situation looks awfully familiar doesn't it? I can think of many more words that have suffered the same fate such as Architecture, Strategy, Risk, Quality, Pattern, etc. as well as SOA and ESB over the last few years too.

In the Business Architecture Domain, 'Capability' refers to the highest-level business functionality encapsulating People, Process and Technology. ‘Capability’ also refers to the value or result of a Business Process sometimes refered to Business Process Capability. In the Technology Architecture Domain, the word 'Capability' often refers to the functions an IT asset provides - I think of these as features or feature sets of a technology. I heard a senior IT executive use the word 'Capability' to describe the existence of a single master the other day. Whoa! Hold on a minute! All of these uses of the word ‘Capability’ are correct but have totally different meanings and it is now cause the word to fail to communicate.

Sidebar: I had a chat with a Business Architect colleague of mine yesterday on the word 'Capability' and they found themselves describing a business process and not a business capability. We resolved that the litmus test for identifying a business capability and not a business process isn’t so much to work from the definition itself but rather to check that the object/entity that you have identified has people, process and potentially technology included. If so, then you have a business capability. If what you have found describes what people do, then it is a business process

One way around this is to add a prefix or qualifier to help ensure the integrity of the meaning of the word. This will help maintain the meaning of it and increase the longevity of the word.

We should instead talk about ‘Capability’ in conjunction with a domain or other qualifier like Business Capability, Technical Capability, Process Capability, Business Solution Capability, etc.