Posts Tagged ‘architecture’

Oracle Service Bus article on OTN

The Oracle Service Bus article Eric Elzinga and I wrote is published on Oracle Technology Network (OTN).

The article is aimed at developers and architects who are familiar with Oracle Enterprise Service Bus (OESB) and are (fairly) new to Oracle Service Bus (OSB). The tutorials in this article highlight differences between these two products. The tutorials are based on a workshop in the WAAI community; a collaboration of Dutch consultancies (Whitehorses, Approach, AMIS, and IT-Eye). The goal of the WAAI collaboration is to share, bundle, and expand knowledge on the recent Fusion Middleware 11g release.

Governing events and architect anti-patterns

As the name suggests, SOA is all about services. What about events? In the past, several SOA-efforts tended to neglect events; ultimately causing SOA not to deliver on its full potential or fail altogether. So SOA-practitioners evangelized the use of events. And of course we as IT-industry came up with new terminology to emphasize this: EDA, SOA 2.0, and event-driven SOA to name a few.

This blog is not about promoting events since its importance is (hopefully!) recognized and events are mainstream in nowadays SOA-initiatives. If not, I encourage you to read this blog that explains why events are important from both business and technical perspective. There can be no real SOA without events. Events are just as important as services!

Presentations Oracle OpenWorld 2009

Oracle OpenWorld and Oracle Develop 2009: It’s a Wrap! Just like last year an awesome event! Read about some of the highlights and experiences in this previous blog.

Lonneke Dikmans and I presented the following two sessions on Oracle OpenWorld 2009 that can be viewed here:

Oracle Open World 2009 highlights

Sitting in my hotel room after the keynote by Larry Ellison that had my ‘all time favorite action Hero and now governor’ Arnold Schwarzenegger as a guest, I was thinking about the highlights of this conference. One of them, obviously, was seeing ‘Arnie’ on stage.

But, on a serious note, there were several highlights as well. Let’s look at them in no particular order.

Architecture in Practice

On May12th I attended a book launch and seminar called ‘architecture in practice’. I worked with one of the authors, Hans Tönissen, in a project. I met and corresponded with The other author, Guido Bayens, on several occasions. The day seemed a bit like a reunion because I met a few colleagues from my past employer too. That felt very nice.

Chairman of the day was Harry van Zon. He connected the different contributions of the speakers very smoothly. The day had six themes:

• The making of the book ‘architectuur in de praktijk’
• The function of architecture within (our) companies
• Professionalizing the function of architecture
• Connecting the architect and other professions within a company
• Innovation with architecture
• Developing architecture proposition

Architecture in practice – Architectuur in de praktijk

The book contains an easy to read explanation of different views on (IT) architecture. The authors have integrated a few of the approaches that are being used in the market today and looked for a way to connect these to TOGAF standards and methodology. I think they did a really good job!
When one looks at the many approaches and ways to do architecture, you realize that an architect can never have in-depth knowledge about all the approaches, let alone apply them. So you really have to work in multidisciplinary teams. I agree with this.
Hans and Guido are looking at the possibility to organize recognized certification for architects. Both are connected to the Novius Architecture Academy and teach there.

After ‘the making of the bookâ’ several other speakers enlightened us with their insights.

Professor Theo Camps elaborated on organizational issues and architecture and talked about the difference between architecture as an art and architecture as a craftsmanship.

After lunch I had to choose between four parallel sessions: The first choice was between ‘developing architecture’ at a large Dutch insurance company or ‘architects and projects’ at the Dutch Railways, the second choice was between ‘governance and change with architecture’ at Province Flevoland and ‘the making of a business architecture’ at Holland Casino. Difficult choices!

Knowledge & skills of an architect

After a short break at 3 pm, we split into different smaller groups to discuss certain topics. I joined the group that discussed what qualifies an architect. We talked about whether an architect should be a generalist of specialist, what rolls he/she has to fulfill, and what knowledge, skills and behavior is needed. Furthermore we identified what you could do (practice) to gain experience and what instrument could be used. Great discussion and very practical suggestions! This is the conclusions we reached:

Knowledge and awareness

• Knowledge of how to get from strategy to design
• Overall business knowledge (generalist) with some knowledge of some domain-specific issues (specialist)
• Knowledge of the (type of) organization
• Awareness of the state of affairs / maturity of architecture and informal structures
• Awareness of the phase the organization and architecture (role) is in
• Knowledge of the roles that are present within the organization
• Affinity with ICT (preferably not too technical)

Skills

• Ability to work together to reach consistency
• Ability to connect architecture with business strategy
• Ability to create a platform for consistency
• Ability to translate architecture into principles and instructions
• Ability to consider organizational design as a constraint
• Ability to direct
• Ability to communicate
• Ability to act as an adviser or partner to C-level management and senior partners of the organization

Behavior

• respect for specialization and understanding of the specialist
• Courage to pioneer
• Patience, continued willingness to teach and explain
• Align with business
• Continue learning

Means

• Getting applicable experience (with change) by doing just that
• Change jobs every 5 years
• Give presentations
• Selling architecture within your own company
• ‘Catch-up talks’ with colleagues
• Take up more difficult or complicated cases
• Horizontal and vertical networking
• Inter vision with colleagues, coaching and training

As I said, I was part of the discussion group, and I agree with all of the ‘features’ mentioned. As an architect you need to have many competencies and skills, but you don’t need to know about everything. With your communication skills, eagerness to learn and ability to connect you will succeed.

The day ended with some networking and I spoke to several nice people. It was a very interesting and nice day. Thanks!

1st international SOA Symposium at Amsterdam Arena.

This was the first symposium that is aimed to be held annually. It was very well organized. The food and beverages were great. I attended both conference days at 7 & 8 October and made arrangements and decorated our booth on Monday afternoon because we were silver sponsor. My colleagues and I decided to stay at our booth for half a day each to meet and talk to interested customers and fellow practitioners.
The first afternoon session I attended was by Dirk Kraftzig: “Conway’s Law and SOA Governance”. Very interesting subject, I thought. This law says that organizations that design systems are constrained to produce designs which are copies of the communication structures of these organizations. Dirk mentioned the law but didn’t elaborate on it. Instead he spoke about 3 business cases with (of course) 3 different solutions.
Next session: “Using Rest and WS-* Together for SOA” by Mark Little. This session was being recorded on video but the cameraman was late. After a 10 minutes delay Mark started his presentation and had to rush to present his slides. What stayed with me was that he wanted to bridge the divide between REST and WS*. I heard a word that sounded like ‘whistle’ for the first time. After the session I asked what it meant because I’m not that deep into IT. WSDL, well…Mark emphasized specifically that REST is not the same as HTTP and showed a model with 7 levels of ‘coupling’. From extreme physical coupling to totally decoupled.
The last session was by Thomas Erl ‘Introducing design patterns’. Thomas gathered proven and field tested design pattern that are sufficiently generic solutions for service-oriented architecture implementations. Some copies of this catalog (900 paged book) were made available at the conference. He advocated that every business domain should (or could) have its own SOA for this is more feasible because there seems to be a SOA fatigue atmosphere . And of course Enterprise wide SOA is very difficult to implement. Some of the patterns sounded to me to lead to ‘fine grained ‘ services.. Away with enterprise SOA and course grained? No, Via (patterns of) cross service transition, data model transformation and rules centralization this could be solved. A bit opportunistic, imho but nevertheless very interesting.
After a book launch and closing keynote there were panel discussions I didn’t attend. In between sessions and in the morning I met some nice people and talked to several acquaintances. I was a nice day.
It was very difficult to choose what sessions to go to on the second day of the symposium. I attended the following sessions:
1. ‘The IBM SOA Governance and management method’ by André Tost: Thorough planned / planning, procedures and responsibilities.
2. ‘Understanding Service Virtualization: taking control of your services by Chris Madrid: Technical; fast talking and information overload.
3. ‘Are Your business processes ready for improvement?’ by Laurent Tarin: BPM trough BPE (ILOG).
4. ‘Addressing SOA fatigue’ by Anne Manes: No nonsense and very understandable, like hearing Anne speak.
5. ‘SOA and EDA benefits and best practices’ by Manas Deb and Clemens Utschig-Utschig: Event handling in SOA, getting used to two different ways to pronounce English in one session
After that, again a book launch; several co authors spoke about their contribution and again I had to tune in to different ways of pronunciation because these co authors come from different continents. Via satellite we could hear Peter Fingar about his book about ’shift 3.0′. The day was closed with 3 panel discussions. Afterwards we cleaned out our booth and went to a Thai restaurant in the center of Amsterdam. We decided not to attend the three day workshops following the symposium.
This was the very first time I took part as sponsor-participant instead of customer-attendee and really enjoyed myself.

1st international SOA Symposium

Yesterday the first international soa symposium started. The location is very interesting: the Ajax soccer stadium. The line up is great: Thomas Erl, David Chappell, and Dirk Krafzig are among the speakers. The content is very good. For the first time in a long time, I had trouble choosing the right track because I would like to follow all of them!
It was also the first time we (Approach) were sponsoring an event. We have a great spot for our booth. It is a nice mix of tool vendors, consultancies and customers at the conference.
The keynote yesterday was by Thomas Erl. He addressed three groups: He appealed to vendors to stick to standards, to the Industry to make standards understandable and to practitioners to make a distinction between different disciplines of SOA.

We are not reorganizing the universe just because we want to do SOA
The first session I attended was by Paul Brown, a well known author from Tibco. The presentation was well organized, and he made relevant observations. The thing that stood out for me, was that he approached the problem of SOA and BPM from the business. He talked about the current silos and stated that these would not go away, just because we are doing soa, or as he eloquently put it “we are not reorganizing the universe just because we want to do SOA”

Another track I was interested in, was the SOA and Web 2.0 track. I attended two sessions. (For some reason, the first one was in the track “SOA Industry”). It was presented by Edwin Sanders and he talked about user interface services. The concept and architecture was interesting, his approach lacked any acknowledgement of common user experience principles. Either the product (corizon) lacks this vision, or the presentation was just unclear. I hope for them, it is the latter…

The presentation by the Burton Group about user experience was very focussed on User Experience. Anne talked about persona’s, Donald Norman etc. Unfortunately the relevance for SOA was explained very clearly. I believe there is a strong link, hence our user exerience service….

In general the sessions and content is very interesting. It would be nice if the program would mention the company the speakers represent. This is very relevant when you select the sessions that you want to attend.

I am sitting in our booth, typing this. I am looking forward to another interesting day. For me this is already a success and I hope that this conference will be continued next year.

Mike in the Approach Booth

Architecture part II

Back to the digital world
In part I of this series we compared digital architecture with architecture of the physical world and mentioned enterprise architecture, reference architecture and project start architecture. In this installment ‘Architecture part II, back to the digital world’ I will explain something about Enterprise Architecture and projects & change.
In part III I will discuss Reference Architecture and Project Start Architecture. Of course there are more architecture types. I will discuss these later.

Enterprise architecture (EA)
In a lot of organizations architectures are made on the basis of the corporate strategy and on strategic goals and objectives. It wouldn’t be right otherwise, right? These architectures are ‘high level’ and have been established to promote the communication between business and IT. The viewpoints discussed and the models drawn in the context of an EA address a range of issues. It addresses problems that are current as well as potential. Thus, the main concern of an EA is the enterprise -wide identification, specification, and prioritization of business needs.
Now and in future.
Only this kind of architectures we can, in my view, call enterprise architecture. No invariable blueprint with a lot of details but a benchmark, as is the mission or vision of the company. It includes much more than a single proposed solution and may even result in multiple, simultaneous implementations. An EA is a more holistic view that unites business and technology needs based on a strategic enterprise vision.

It seems obvious that such an enterprise architecture is laid down as a kind of law by the governors of a company, such as the CEO, the CIO or a Board of Directors. You must consider EA as the IT strategic plan of the enterprise. It serves to give consistency and identifies dependencies. It outlines which direction must be followed and gives direction to the desired consistency of services, business processes, organization development, use of data in the information system, applications, and technical infrastructure in the organization and contains explanatory pictures and the most elementary construction rules.

EA and change
EA concepts have been around for a while. In due of accelerated environmental changes in organizations of all sizes across most industries business agility and, in particular, the ability of the technology infrastructure to respond to change in a timely manner have reached critical importance. That’s why the enterprise architecture discipline has gained such momentum.
Another factor contributing to a growing appreciation for the enterprise architecture discipline has been the more stringent regulatory climate, which is driving organizations not only to improve their accountability and reporting practices, but also to make compliance organic to every business process.
In response to this sharper focus on EA principles, enterprise architecture ‘paradigms’ have emerged, such as TOGAF ADM (the open group architecture framework, architecture development method) and Zachman’s framework , IFEAD (The Institute for Enterprise Architecture Development) and NORA (Nederlandse Overheid Referentie Architectuur) However, they differ substantially. E.g. because Zachman is a framework, TOGAF a method and NORA focuses on SOA and is meant for Dutch governmental organizations, etc.

EA to guide change
An enterprise architecture is subjected to change as the mission and vision of the organization and business requirements becomes more clearer and the companies environment is changing too.
When big changes are to be realized we tend to cut them in to smaller multiple projects we call ‘change programs’. The enterprise architecture can be used to guide these changes.

The translated desired company characteristics guide the need of projects and change programs and gives implications of these changes. Thus it is a means for architects, information managers, business consultants, design teams, designers and EDP-auditors to be able play their role, in projects or change programs, well.

With enterprise architecture you can:
 Recommend the management and program management about choices. (some models translated in more communicable pictures and drawings.
 Make frameworks to outline architectures at the start up of projects
 Proactively (give direction, train) guide designers
 Review of products (reactively) from change programs on content and consistency.
 Give business consultant, design teams and individual designers a ’stocked backpack’ so that they are able to follow direction and make the correct choices.
 Use it as reference by the internal Audit Department and external EDP-auditors.

The success of the concept of ‘changing under architecture’, through guidance from EA not only depends on a common, coherent picture of where an organization wants to be in future, but at least as much of the way the organization wants to achieve this and the willingness to adapt to change if necessary.

This asks for an intensive cooperation between architects, business people, the IT department and to a process in which it is clear & has been decisively agreed upon, how further interpretation, adaptations and deviations on architecture are realized.

When architecture is of that type, it really offers an ‘instrument’ to reduce the risk on loss of substantial consistency and give means to manage consistency. Guaranteeing consistency can, on the one hand, be realized by following construction principles of the company and on the other hand, by getting integrated insight in the structure of the company, by applying these principles.
This gives a grip on design, development, implementation and management of the renewed part of the organization.

Back to the physical world?
The function of an enterprise architect can be compared to that of a city planner. In contrast, the function of a ‘building’ architect is more readily associated with the IT architect role. The enterprise architect role often emphasizes the inductive skills of a detective over the deductive skills of a builder. However, the high-level perspective of the enterprise architect does not mean that this role is disengaged from the user community. On the contrary, an enterprise architect must be involved in helping customers understand their real needs (as opposed to wants) and to work with them throughout the implementation of a solution.

At the same time, an enterprise architect should be able to view his or her domain at a level of abstraction that prevents direct involvement in the practical aspects of implementations.
An enterprise architect should be able to understand the business problem and the business domain and explain it to the technical people and to be able to understand the technology domains and explain the technical possibilities to business people.

It is important that an enterprise architect plays a pivotal role in architecture governance, a function that is often either shared between assorted business and technical roles or, even worse, simply ignored. Architecture governance is the glue that provides both a context and a framework for all enterprise and project architecture activities.

SCA to eliminate “over-servicing”

When Oracle acquired Collaxa and its BPEL product, there was no Oracle ESB yet. All adapters -such as file, FTP, JMS and database adapters- and complementary routing and transformation functionality were directly used from BPEL processes. Later on, Oracle introduced its ESB product and advocated to place adapters in the ESB instead of BPEL PM. That made sense since it promotes a cleaner separation of concerns. After all, adapters are more a technical, infrastructural concern than an orchestration concern. Mostly due to backwards compatibility, adapter functionality remained a part of the BPEL PM product. This caused much confusion since it was not always clear from where to use these adapters.

When you follow the above design guideline of placing adapter functionality in the ESB-layer, you could end up with masses of ESB projects in a real-life SOA implementation. Think of it, there can be tens -or maybe hundreds of BPEL processes and composite services- of which several will invoke partnerlinks that are in fact ESB projects wrapping adapter functionality. Examples are retrieving data from a database, publishing an event, FTP-ing an order file to a supplier, etc. This leads to “over-servicing” since some of these ESB projects are not reusable (low-level) services, but local to a single composite service or process only.

The amount of ‘none-reusable’ services depends on the approach taken. Losing overview is one of the risks of implementing SOA in bottom-up fashion only. This can result in too many granular, and possibly none-reusable services. It can be prevented by applying a more top-down or meet-in-the-middle approach. This will lead to less none-reusable services. However, you’ll always end-up with some services that are ‘private’ or ‘local’, meaning that they are only used by one other process or composite service. In such cases you would like the ESB service to be local -or encapsulated- to the composite service or process without moving the adapter functionality to BPEL.

The great thing about the Service Component Architecture (SCA) standard -on which Oracle SOA Suite 11g is based- is that you do not need to expose low-level mediator services and adapter functionality as a separate external service. It can be a local component to a composite and therefore not visible to other service composites. This promotes much better integration and encapsulation of infrastructure and low-level services. You only need to expose those artifacts that are -or will be- reusable. This resembles some of the OO-principles such as encapsulation. However, if a project ends up with lots and lots of none-reusable or ‘private’ services, it might be a good idea to analyze the services and process in a more top-down fashion to be able to create better reusable services.

Architecture part I: ‘high level architecture’

Do we need architecture?

In experience, there is always much discussion about the usefulness or need for architecture in organizations. And, even when people agree having architecture is useful, discussions go on about whether to have enterprise architecture (EA) or reference architecture (RA). In my current environment, EA is defined as a slender framework containing strategic models. RA is considered a big framework with much more details and constraints and therefore much less receptive to change. Apart from the discussion about the usefulness of architecture in general, there is a lot of debate about a so-called project start architecture (PSA). That’s why I think it’s important to get clear understanding what architecture is, and why you would want one for your organization. At least in my opinion perhaps we can agree later on what name to give these architectures.

In the first part of this series, I will first explain about architecture and architects in general. In the next installment Architecture part II, back to the digital world I will explain something about projects, change & Enterprise Architecture.
In part III I will discuss Reference Architecture and Project Start Architecture. Of course there are more architecture types. I will discuss these later. The last part of this series is about whether architecture can be agile or not.

Architect and architecture in general

The term ‘architect’ has a very long history. It descends from the Sanskrit words arh and takshati which respectively mean ‘merit able’ and ‘he that forms or constructs’. From these words stems the Greek terms `archi’ and `tekton’ meaning ‘head’and ‘craftsman, professional or artistâ’.
The architect therefore, is someone who understands the art to form and construct, to make architecture. He first starts drawing a mental model of reality in his mind. Then a physical model (a picture drawn on paper) is made to represent the desirable reality. Next, construction principles and conditions are added. Then designers use these frameworks to make more detailed designs. All this to have a ‘blueprint’, so builders and other construction workers (e.g. bricklayers, carpenters and plumbers m/f) effectively can do their jobs and realize the architecture in reality.
Of course these architect and craftsman are from the physical world.

We can, however, compare the digital world of architecture with the physical world of architecture.
Letâ’s create an analogy to city engineering architecture, the architecture of specific town districts, the architecture of the individual buildings, the interior design & the associated design of furniture and equipment and the infrastructure in regard to roads and public utilities.

We have enterprise or reference architecture at organization level concerning the enterprise. These include the whole companies architecture divided in, let us say, domains. You can compare this with the city planning of a town district. At this level of architecture you must be able to see the high level picture. The enterprise processes and their relation to customers and other interested parties (stakeholders).
The Information architecture compares with the design of the buildings. To be able to realize the ‘architectural domains’ you need high level principles, rules and directives that are useful in the domains. You can compare application architecture with interior design.
(Technical) infrastructure architecture connects the whole with the choice for software and hardware. To put it in other words; the latter compares with roads, plumbing, sewerage, telephone wiring, lifts and staircases etc.

The physical architecture levels compared to the digital architecture levels look like this:

Let’s keep following the analogy.
An organization strategy formulates the reason of existence of an organization. Her mission and vision could be seen as the start/ basis for the city plan which contains the steps to realization of the residential area. To build the houses, the bicycle paths, shopping center, public utilities, bus stops, the medical center we are very eager to use the expertise of architects.
These professional folks make the destination plan alive at high level, devising the vision into pictures and images. These images come to life in arranged photographs, sketches and construction models. These architects know about the construction rules and other dependences that have to be taken in to account when the wishes of the occupants and visitors of the town districts must come to reality.

Architecture can be an instrument to secure consistency of plans, to help respect the relevant construction principles and give some grip to all contractors and subcontractors who must execute and implement the detail designs to make a working whole. Architects know the relations between (plans concerning) residential areas as they have an overview of the complete town destination plan.

A good city plan ensures that eventually everyone knows, what must come where and in consistency with each other. And this is not only because we want to prevent that the bus lane runs between consultation room nr. 4 and 5 in the medical center. We also want to be sure that no drinking water comes from the electricity cable. Or, when the one occupant impregnates the toilet some other occupants light goes out. Or nastier, when cooking gas comes out the power outlet when you put in the plug.

It’s just an analogy
As any other analogy, the comparison is for making things easier to understand. There is a major difference between ‘building’ architecture and software (system) architecture: A lot of decisions made in construction are hard to change. It is very difficult to go back and change your basement, although it is possible. Software is not limited by physics; buildings are. Change to software is limited by imagination, by design, by organizational bias. I will discuss this concept of agility and architecture in the last part of this series.