Archive for the ‘Architecture’ Category

Unicom EA Forum

Thursday, September 22nd, 2011

Philip Boxer and Richard Veryard will be speaking at the Unicom Enterprise Architecture Forum in London on Thursday September 29th.

We have a few free tickets, so please contact us in the usual way if you are interested. Alternatively, please add your name to the Linked-In event notice. http://events.linkedin.com/Enterprise-Architecture-Forum/pub/746066.

Update Links

Summary

Philip’s presentation on Slideshare
Supporting Social Complexity in Collaborative Enterprises

Richard’s presentation on Slideshare
Next Generation Enterprise Architecture (EA)

Limits to the Use of the Zachman Framework in Developing and Evolving Architectures for Complex Systems of Systems

Wednesday, May 6th, 2009

by Philip Boxer

This presentation was given in collaboration with Suzanne Garcia at the Fifth SEI Architecture Technology User Network Conference on Architecture at all Scales, May 4-7 in Pittsburgh.

Software architects are increasingly being asked to address how their architectural representations relate not only to those of systems (of systems) engineers, but also to the views commonly found in DODAF (Department of Defense Architecture Framework) or other enterprise architecture frameworks. In many cases, these requests made to software architects are part of trying to understand how one software system is likely to interoperate with others that are either inside or outside of the enterprise. Understanding some of the limitations of the Zachman framework and DODAF 2.0 in understanding both software architectures and interoperability in complex systems of systems should make it easier for software architects to place their architectures in relation to these other common frameworks. This presentation describes proposed modifications to the Zachman framework that are required to account for the needs for cross-enterprise collaboration and for accommodating new user needs at a rapid pace. The presentation also highlights a set of modeling elements that are commonly found in multi-enterprise situations. These modeling elements are illustrated in reference to DODAF 2.0 entities to emphasize what is currently missing. The presentation concludes with an example from a modeling approach that addresses these gaps, which is used at the SEI to describe not only the social and technical aspects of systems (including software systems), but also their relationship to the changing demands (especially user needs) placed upon them.

Enterprise Architecture for Complex System-of-Systems Contexts

Thursday, March 26th, 2009

by Philip Boxer

This paper was presented in collaboration with Suzanne Garcia at the 3rd Annual IEEE Systems Conference in Vancouver March 23-26 with the following abstract:

An enterprise architecture is an accepted, widely used means for an organization to capture the relationship of its business operations to the systems and data that support them. Increasingly, enterprises are participating in complex system-of-systems contexts in order to meet changing customer demands that require them to collaborate with other enterprises in new and innovative ways. For a complex system-of-systems context, a shortcoming of enterprise architecture is that it presumes a single enterprise or a single, ultimate source of control.

This paper explores an approach to reasoning about distributed collaboration in the complex system-of-systems, multi-enterprise context, in which this single, ultimate source of control does not exist. It outlines the ways in which the long-used Zachman Framework for enterprise architecture would need to be modified to account for multi-enterprise collaboration and decentralized governance. It proposes a concept of stratification to meet this need and puts forward the main characteristics of the methods needed to model the stratified relationships of complex systems-of-systems to their contexts-of-use.

Business as a Platform

Sunday, March 19th, 2006

by Richard Veryard

A business can be regarded as a platform of services. This has important implications for the (variable) geometry of the single firm, as well as the interoperability of multiple firms.

Amazon is a platform. eBay is a platform. (See report on eBay by Dare Obasanjo). Their business model involves providing services that other companies can build upon. Following this thinking, we end up with a stratified business stack, with businesses building upon other businesses. This is the world of the mashup – but it is also the world of serious enterprise interoperability.

Many businesses are trying to turn themselves into platforms. In his post on Disney, Pixar and Jobs, John Hagel argues the point for media companies. (I mentioned this briefly in my post on Disney, Pixar, Apple and Jobs.)

In a world of scarce attention, creators of media products will need to compete with those who re-conceive media products as platforms. What is the difference? Products are designed to be used on a standalone basis – you buy it and you view it or listen to it in the specific way the content creator intended. Platforms are designed to be built upon – they create opportunities for the original creator, third parties or the customers themselves to extend, enhance and tailor the content in ways that the original creator never anticipated. Offered as a platform, content can create far more value than any equivalent standalone product.

Many companies already have a platform, but they are trying to raise it. For example, the traditional role for telecoms companies is as a platform of telecoms connectivity. But it has been obvious for ages that there is no long-term profitability for telecoms from providing services at this level. So telecoms companies have long understood the need to raise the platform, to offer higher-value services. But they are still struggling to formulate and implement this strategic change. Why is it so difficult?

One reason for the difficulty comes from the asymmetry of demand, which generates complexity in the business stack. The height and configuration of each platform is a difficult strategic question: too low and you leave a value deficit, too high and you lose the economies of scale or scope, too inflexible and you can’t respond to change.

And how is the whole stack going to be organized, for whose benefit? This is a key question for asymmetric design.

Architecture Podcast

Wednesday, January 11th, 2006

by Richard Veryard
A 40-minute podcast Philip and I recorded with Ron Jacobs in December has been released on Microsoft Channel Nine.

0:00 Introduction
1:58 Governance Ron
2:32 Asymmetry Philip
3:39 Value of SOA to business – the adaptive enterprise Richard
5:25 Asymmetry – Medical Example Philip
6:44 Silence
7:07 Impetus for SOA – take costs and risks out, put value in Philip
7:47 Fluctuations in demand volume Ron
8:06 Implications for the relationship between service provider and consumer – does the service provider know what the fluctuation means for the consumer – efficiency versus flexibility Richard
9:44 Implications of interoperability in the real-time enterprise – supply chain example Philip
10:49 Interoperability from demand-side perspective – joined-up-government example Richard
13:18 Governance at the edge of the organization – asymmetric governance Philip
15:32 Metropolis and city planning as metaphor for SOA governance – Christopher Alexander and the Nature of Order Richard
17:48 4-colour workshop – Blue, Red and White – the role of Enterprise Architecture Richard
19:02 City planning example – city planners as enterprise architects Ron
20:14 4-colour workshop – the role of the Black team – anticipating the challenges of the response to demand Philip
22:44 Enterprise architecture that fails to deliver adaptability. Problems with universal models. Richard
24:22 So who does the black team thinking? Examples from public sector, military, telecoms industry, voluntary sector. Philip
26:41 Anticipation of context in which demand emerges Philip
27:30 Internet business models – Pareto thinking versus “long tail” thinking Richard
29:26 Paying attention to customers one-by-one – customer context – school example Philip, Ron
30:25 Whose priorities – provider’s interest versus consumer’s interest – school example Richard
31:33 Diversity of interest – patient records example. Philip
32:12 User defined meaning – del.icio.us and technorati Richard
32:42 Consumer-side flexibility – agile systems Philip
34:30 Banking services and user-defined policy Richard, Ron
38:38 Close Ron

Responding to diversity in Value Models

Friday, December 23rd, 2005

by Charlie Alfred
Philip, Thank you very much for your comments on separating the supply-side from the demand-side. I agree with the points you raised, and have a few observations to share:
1.
You observed that my article approaches the problem from the provider-side. Given the nature of my job, my original goal was to teach people I worked with about how to do a better job of software architecture. This is the main reason that the article takes this point of view.
My belief is best expressed by Dr. Russell Ackoff, former professor at the Wharton School of Business. He discusses the sibling processes of synthesis and analysis. He observes that analysis has been the predominant model of thought since the Industrial Revolution. Take a whole, break it down, and study the pieces in isolation.
Ackoff suggests that while analysis helps you to explain how things work, it doesn’t give you enough context to understand why they need to work that way, and what might cause them to change. To do this, you must study how a subject (system) functions in its larger context(s). This begins to expose which expectations, obstacles, and constraints are imposed on the subject.
In short, as a result of this research, I’ve come to the conclusion that an architect needs to:

    a) start with synthesis to understand context (both shared and diverse),
    b) use analysis to formulate approaches to challenges, analyze trade-offs, and mitigate risks, and
    c) use synthesis to consider the feedback effect of the solution on the contexts, etc.

Ackoff’s writings have also convinced me that the scope of a system must expand to include all elements with significant inter-dependencies. The little bit of thinking that I’ve done on the subject of value suggests that the consumer and supplier sides cannot really be considered independently. This is the subject of my next observation.
2.
You mention the two perspectives of value: consumer-side and supplier-side and raise the question about whether they can (and should) be considered independently or must be considered together.
As a general rule, I think that they cannot be considered in isolation:

    a) In the long run, there is no supply-side value where there is no demand-side perceptions of value. In cases where demand-side utility curves are strong and inelastic, and suppliers have major market power, “long run” can be quite a long time. For example, OPEC can ignore the needs of its customers for price, supply, and to a lesser extent quality. However, this has the side effect of stimulating research into alternate sources.
    I agree that diversity on the demand side tends to strongly influence market segmentation in more competitive markets. While this happens a lot in dynamic markets, it also happens in ones that were thought to be stable. Southwest Airlines low fares/low cost approach has been extremely effective against United, American, and Delta.
    b) Supply-side innovations often change utility curves on the demand side, by changing consumer’s perceptions of what is possible. Today, I can’t write a paper or report without having my web browser open and Google ready to run. My iPod Nano is so small and holds so much music that I want to take it to work. If I’m away from home and need to make a phone call, I pull my cell phone out of my pocket.
    10 years ago, I was quite content without any of these things. It wasn’t that I was unaware of the benefits of instantaneous research, portable entertainment, or accessible communication. The main reason I was content with less than that, was that I had no idea that major improvement was possible. However, once exposed to the innovations, my utility curves (and hence, my value expectations) were reshaped for ever.
    c) When faced with significant diversity in value perceptions by consumer, a provider can be faced with a difficult juggling problem. If the provider attempts to craft individual solutions, its development and operating costs can go up. If the provider attempts to create a solution that can be tailored to each context, it risks creating something that doesn’t fit any of them very well.
    Consider a sport utility vehicle. Buyers who like to drive it off-road want a lot of ground clearance. Suburban moms like the fact that a higher clearance gives them better visibility of the road. However, a higher clearance also tends to mean a higher center of gravity, which increases the risk of rollover in sharp turns. This is not much of a plus for the driver who wants the all-wheel drive for driving in snowy and icy climates.

In summary, the consumers and providers both win when the provider understands the value models and challenges well enough to combine the right set of diverse needs into a solution, while omitting the ones with incompatible challenges.
3.
I agree completely with your point about Porter’s use of horizontal and vertical linkages. To me, the notion of linkages was key, and differentiating between those that are internal and external was less significant.
I find it more interesting that the “architectural decisions” of the firm (value change) are what determine its cost and differentiation drivers. For example, an airline like United has chosen a hub/spoke architecture and a variety of airplane types. This lets it have very frequent departures and match aircraft sizes to the flight lane. OTOH, Southwest standardizes on a small number of aircraft and prefers direct flights. This lets it reduce the costs of training and maintenance, and reduce the cost of operating large hubs. The different business architectures appeal to diverse sets of passengers, because the passengers have different utility curves. In effect, linkages tie directly back to the value models of the consumer(s) and provider(s) and the constraints that the environment enforces on its own (e.g. how far can a 727 fly without refueling?).

As a related note, I love Christensen’s concept of discontinuous innovation.
In summary, I believe that necessity is the mother of invention, and value model diversity on the demand side will force the supply side to better satisfy it. It may not be a painless transition, because a lot of firms haven’t learned how to:

    a)Forget about their own agenda, and immerse themselves in their customer’s context
    b)Learn how to be jugglers and figure out which things can be juggled together and which cannot.

Let me know what you think.
next in this thread

Value-Driven Architecture

Saturday, December 17th, 2005

by Charlie Alfred
I am the author of an article on Value Driven Architecture. I finally had the opportunity to read your article on Governance during the past couple of weeks, as well as the earlier one you reference (Metropolis), written by Pat Helland.
It was very interesting to see how you both took the concept in different directions. Pat focused on the service-provider side, and emphasized the benefits of standardization and high-speed transportation (networks). You took a more systemic view and emphasized how diversity often is not limited to service provider implementations, but instead reaches more deeply to affect the service API’s as well as the workflow management (or other control structures).
Someone at the 2004 Software Product Line Architecture conference in Boston made a very interesting observation:
“The ROI of a software product line comes from leveraging the commonality. However, you cannot achieve this effectively until you also identify and manage the variability.”
I believe this quote sums up a lot of the philosophy difference between Pat’s article and yours. Pat seems to be making the “benefits of leveraging the commonality” argument, while you do a very good job of articulating how difficult “managing the commonality” can be.
Both of these notions are essential and relate back to one of the central themes of the article I wrote on “Value Driven Architecture.” In order to know where to accommodate diversity and where to leverage commonality, you must have a way of identifying and contrasting context-specific challenges (where each context consists of a set of like-minded stakeholders who are affected by equivalent obstacles and constraints). By contrasting the key challenges and their priorities side-by-side, the architect begins to clarify which challenges are similar enough to leverage with a standardized approach, and which ones require more diverse approaches.
Again, thanks for the thought-provoking article.
next in this thread