Approach was asked to advice the school on how to make best use of ICT resources for creating schedules for students and teachers and the formation of the teachers workforce.

In summary, the experienced problems were  late completion of grids/schedules and therefore late insight on how many and for which subjects to hire teachers. This also depends on prognosis  on how many new students registered, how many student proceed to next school year and school type and has great consequences on school budget . Our first view on the case was that content of programs and applications were not synchronized, information wasn’t up to date and necessary information not congruent.

In order to give a practical and good advice we first had to identify the most crucial problems regarding process, what IT resources where available, in what manner IT resources were used, and what priority solving a problem has to the school stakeholders. To find out what bothers most, takes the most time, how many and which stakeholders are involved, we held interviews with all stakeholders.

Machiel has in-depth knowledge and experience on how IT systems work and knowledge on some pretty important lean practices. Mary is expert in BPM methods &  techniques and has experience in solving organizational issues. Working together enabled us to take a multidisciplinary view at the problem and to assemble the best and most valuable advice for this customer.

In the interviews we walked, step by step, thru the whole end-to-end process to see where bottlenecks occur, where transfers to other roles were necessary (or not) and which IT resources were used to support stakeholders and process. We didn’t use a sophisticated tool, just rounded A5 papers and pencils or whiteboard and markers to make process visible.

In short, problems were caused by low assessable homemade systems (access dbase, spreadsheets), synchronization of information between homemade systems & commercial products and between Do-It-Yourself systems themselves. Furthermore, process was not ranged optimally and errors easily occurred. Limited accessibility to the content of programs and applications (for example the scheduling makers) and various officials at different times and places making changes in program content.

For quick wins Approach, amongst others,  advised on making clear decisions on moments and responsibilities within the end-to-end process, communication and governance on decisions  & appointments  and improvement on the use of (DIY) systems by supplying a ‘howto’.  For long term alleviation, Approach suggested sensitive communication to understand who needs what information in which step, where an inaccuracy cascades in multiple errors further on in process and disciplined actions for controllability and management.  And we recommend on further research on functionality, integration capabilities and interconnectedness of their existing or future IT resources.

When we presented our report, stakeholders said they didn’t expect to get such advice. They expected something like: ‘get rid of your IT resources, DIY systems and buy ‘this’ one’.  At the end of the presentation session we helped stakeholders to realize about their own responsibilities in the process and to decide about the next approach. The school leaders expressed they were very pleased.

Neem voor meer informatie over onze dienstverlening op het gebied van software ontwikkelprocessen contact op met Lonneke Dikmans of Machiel Groeneveld.

Heldere communicatie is een belangrijk element in de beeld- en begripsvorming over Approach. Daarom hebben wij gemeend juist te investeren in het ontwikkelen van een nieuwe website. Deze is opgemaakt in onze huidige huisstijl die de warme persoonlijke uitstraling, die wij nastreven, accentueert.

Wij willen met deze site onze klanten, partners en relaties meer inzicht geven in alle mogelijkheden die Approach kan bieden. Op de nieuwe site is meer informatie te vinden over onze services, solutions en consultancy activiteiten. En natuurlijk voor wie wij allemaal actief zijn.

Integrating OID 10g with SOA Suite 11g
Using OID 10g as identity- and access provider in SOA Suite 10g wasn’t entirely trivial. After applying the steps as documented in Oracle BPEL Process Manager Administrator’s Guide 10g you needed to perform some additional configuration steps that could be somewhat tricky at first. Jaap Poot has some great blogs on this.

How different in SOA Suite 11g. Just configure OID 10g as security provider in WebLogic Server Administration Console and you’re done. No need for running Ant scripts, performing lots of post-configuration, and so on. Just follow the steps as listed in the Oracle Fusion Middleware Administrator’s Guide for Oracle SOA Suite 11g Release 1. And don’t forget to set the control flag to SUFFICIENT for every provider, including the DefaultAuthenticator. If you set the OID provider to SUFFICIENT and DefaultAuthenticator to REQUIRED, you’ll see the OID users and groups in WebLogic Server Administration Console, but not in JDeveloper or the BPM Worklist application.

SOA Suite 11g supports only one identity- and accessmanagement provider, while WebLogic Server supports chaining of multiple identity- and accessmanagement providers.

After restarting WebLogic Server, the users and roles in OID 10g are available to the Human Task editor in JDeveloper (of course, you need to configure a connection to SOA Suite 11g):

And also to the default SOA Suite 11g BPM Worklist application, that can be accessed at http://host:port/integration/worklistapp (e.g. http://localhost:8001/integration/worklistapp).

The final step is to add the user “weblogic” and group “Administrators” to OID 10g. This is documented in a different document, and can therefore be overlooked. See 27.2 Logging In to Oracle BPM Worklist.

Permissions in SOA Suite 11g (such as workflow.admin) are mapped to principles (such as SOAAdmin). These principles are then member of groups (Administrators) that need to exist in the used identity and access management solution. Since the group “Administrators” by default does not exist in OID 10g, you need to create it and assign the users to it that need to have the specified SOA Suite 11g permissions. For example, permission to change settings in the BPM Worklist application or authenticate on behalf of another user. The other groups such as BPMWorkflowAdmin were already present in OID 10g as seeded there during configuration of SOA Suite 10g.

The mapping from principles to groups is configured in the user_projects/domains/soa_domain/config/fmwconfig/system-jazn-data.xml file. You can view and edit these application policies and application roles in Enterprise Manager Fusion Middleware Control. Select: Farm_soa_domain –> SOA –> soa-infra –> Security –> Application Policies (or Application Roles).

So, that’s great. Configuring OID 10g for SOA Suite 11g takes less than an hour.

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.

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!

So everything hunky-dory, right? Then why are some SOA-projects using events at runtime to model business processes and their interactions and enable loose-coupling, but neglect to address the governance aspect?

• Organizations set up SOA-registries that include and publish services but not events. Service consumers can discover services, reuse them, retrieve metadata such as ownership, contract, interface, and so on. What about event consumers? What about including events in your registry?
• Architects design taxonomies that structure services into various layers (business services, composite services, and elementary services) and domains (finance, CRM, sales, etc.) but have no taxonomy for events.

Bottom-line: not only use events at runtime, but make events an integral part of your governance processes just as you do for services and processes. That enables reuse of events, dynamic event-discovery, lifecycle-management of events, and so on.

What I’m wondering though if there is a ‘one-size-fits-all’ solution when it comes to governance of services and events? Does the same taxonomy apply for services and events? Is the lifecycle for services the same as for events? Is the metadata we need and store for effective governance the same for events and services? Do you want to unify governance for services and events?

Some experiences might suggest so. We could structure events into business events, composite events, and elementary events. An event has a contract, interface, and implementation. An event has event producers and event consumers. An event has an owner. An event can be discovered. An event provider can guarantee message delivery. An event can be under development, in production, deprecated, retired, and so on. Replace event with service in these last few sentences and it all seems to fit.

However, I don’t want to rush to conclusions and try to squeeze everything into one all-knowing overall model. Guess that’s a known architect anti-pattern: everything has to fit the boxes we draw and models we think of. Even if reality fails to fit in. We rather try to alter reality then to change our models

Obvious differences would be that the consumers of services are generally known whereas event consumers could be unknown (hence also better decoupling). This has different consequences for services and events when it comes to dependency management and impact analysis. Also, events and services could have some specific attributes such as consumer type for events: single (queue) versus multiple (topic).

In any case, I’m going to find out! For a new customer project I’ll be defining the business, information, and technical architecture around services and service-registries and define their governance processes. And guess what? We’re going to include events in this effort. Let’s see what the result will be.

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

Approach to Oracle Fusion Middleware 11g
This session presents an approach to the strategic Oracle Fusion Middleware 11g components, using a customer case and in-depth knowledge of the new Oracle SOA Suite 11g. The case study covers a car leasing firm that migrated from Oracle SOA Suite 10g and Oracle WebCenter 10g to Oracle’s strategic platform with Oracle WebLogic solutions and Oracle Application Development Framework 11g.

Topics:

• Overview of the customer’s SOA environment and infrastructure
• Migrating to Oracle WebLogic solutions and Oracle Application Development Framework 11g and how a SOA environment affects the transition
• New features of Oracle SOA Suite 11g and how to migrate to it, with a focus on Oracle Service Bus and Service Component Architecture

Portals: The Way to Realize User Experience in a Service-Oriented Architecture? (IOUG/ODTUG)
Portals seem like a natural fit for realizing the front end in a SOA. This session describes two customer cases in which portals were used to present services to end users. In the first case, a Dutch municipality used Oracle Portal in conjunction with Oracle SOA Suite to offer personalized information and products and services to citizens. In the second case, a car leasing company used Oracle WebCenter as a process portal for users for part of its procurement process. In both cases, the portal did not offer the expected benefits to the organization or the end users. The presentation covers possible use cases for the application of portal technology and the critical success factors for portals in SOA and BPM environments.

• Identity management
• Authentication; including Single Sign-On (SSO)
• Authorization
• Logging and monitoring
• “Hard” security; more technical security including confidentiality and integrity of data, usage of firewalls, IDS/IPS products, and so on.

The first three together encompass Identity and Access Management (IAM). “Soft” security like creating security awareness, training employees, applying physical security to buildings and IT-assets, and availability of IT-assets (together with confidentiality and integrity forming the so-called CIA-triad) are out of scope for this blog.

Security and SOA
When compared to traditional software development the important question is not whether security in an SOA-environment is important, but if it is any different -and should therefore be designed differently? The answer to both questions is yes.

To understand why security should be handled differently we need to understand the characteristics of SOA that are key to the security aspect compared to those of traditional software development:

• Next to human-machine interaction there is more machine-machine interaction. This means there is a greater need for automated security mechanisms for purposes of authentication, authorisation, encryption, and so on.
• A SOA-environment generally contains more intermediary stations such as ESB’s and other middleware components. There are more locations for users and administrators to view -possibly confidential- message contents such as credit card information. In this case transport security alone is not enough.
• How can you manage and control various (external) clients that want to access data and/or services if systems are loosely-coupled? E.g. not every client must be allowed to invoke a banking service.
• SOA results in more Straight-Through-Processing (STP) meaning processes are more frequently executed in an entirely automated fashion without human interference. Good security is key since consequences of possible security breaches could be detected later on. Also, the consequences can be graver due to the possible large amount of process instances.
• Services are invoked by both internal and external consumers. A service’s security level is usually determined by its owner. In case of external services, security will be largely determined and enforced outside an organization’s own span-of-control. The level of security determines the consumers trust: “What happens with my data if a service is not secured?”, “Can I trust a service’s result?”, and so on.

These differences clearly impact the way security should be designed within an SOA-environment. It furthermore warrants the need for an integrated and holistic approach on security in an SOA-environment. Use a layered approach to security as for example promoted by the defense-in-depth strategy.

Externalize security
For a number of reasons it is a good design-principle to externalize identity management and security; even more so in an SOA-environment that frequently consists of heterogeneous infrastructure. Every service having its own IAM and security design and implementation leads to a suboptimal solution, more overhead, and greater chance for security breaches. If security is part of the infrastructure’s components -for instance intertwined in an ESB product- different products will most likely also support different security standards and protocols. E.g. an application server might support SAML version 1.1, the WS-Security Username Token profile, transport security using HTTPS, and LDAPS while the ESB product supports SAML version 2.1, the WS-Security X.509 Token Profile, message security using XML DSIG, and LDAP rather than LDAPS. This is worsened in case external infrastructure supports yet another subset of standards and protocols. This can cause poor interoperability. Use a separate -specialized- component for security instead. This promotes both reuse of better security throughout your SOA-environment and promotes separation of concerns.

The agents and gateway patterns are very well suited to externalize security. Use gateways for appliance of common security policies and agents for more service-specific security policies.

Security classification
Define a limited set of security classifications; for example based on the CIA-triad (confidentially, integrity, and availability) ranging from e.g. “public” to “highly classified”. Determine a minimum set of security measures per classification level. For each new service determine its classification levels; this is usually the responsibility of the service owner. Make classification levels part of your service repository and governance processes. This results in more understandable security regulations, gives better insight in the current and future security of your environment, better reuse of existing security policies, and prevents reinventing the wheel when establishing security for new services. Most important it results in just the right amount of security to be applied; thereby saving money (strive for the lowest possible classification levels without endangering security) while applying (just) enough security.

Transport versus message security
There are roughly two types of security for message invocation: transport and message security. Transport security secures a message only during transport between service consumer and service provider using the transport layer; e.g. using HTTP over SSL or TLS (HTTPS). That means messages are not protected in intermediary components such as an ESB and not protected directly after being received by the endpoint. Message security secures the message itself, mainly through encryption of the payload using for example public and private keys. Since message security can provide security in the scope you want to -so also in intermediaries and after the message has been received- it is generally preferable over transport security. Both transport and message security can be used for authentication (e.g. signature based on certificates), integrity (e.g. digest), and confidentiality (e.g. encryption).

Standards
Maybe trivial but very much important: use standards to promote interoperability. This includes the usage of security standards such as LDAP(S), HTTPS, SAML, XML DSIG, WS-Security (WSS), and other WS-* standards. Using standards results in secured services being reused by (both internal and external) heterogeneous infrastructures. Next to technical standards there are also a number of security reference architectures and principles and guidelines you can leverage.

Before we wrap up some best-practices per area.

Identity management
Use a centralized identity management repository. This avoids duplicate user management and possible inconsistencies. Divide users into different identity types if needed -such as employees, customers, suppliers, and so on since different rules and administration may apply to each category. Be careful in allowing external IT-assets and organizations direct access to your identity management solution. Consider identity provisioning in such cases as external hosting to minimize security risks.

Usually you want a service provider to authenticate the original service consumer (user identity) and not some intermediary component such as an ESB. Implement identity propagation of tokens, username/password, etc. so the service provider authenticates and authorizes the identity of the original user that invoked the service. That implies that all intermediary components between service consumer and provider need to be able to transport identity tokens -and possibly transform these from one format to another (e.g. from SSO token into username/password).

Especially in case of authenticating and authorizing external organizations consider the trade off between using specific identities (Mr. X or Mrs. Y) versus more general identities (organization Z). Specific identities result in better traceability and can provide for more fine-grained access control while more general identities can result in less administration: the number of different identities to manage and synchronize decreases dramatically.

Avoid generic identities such as “consultant” and “trainee” all together.

Authentication
Define a limited set of authentication levels and differentiate on information (password), possession (token, physical key, text message to a phone), and attribute (voice, fingerprint) as mechanisms. E.g. “basic-level” authentication requiring information, “middle-level” authentication requiring information and possession, and “high-level” authentication requiring attribute or possession together with a check of ownership.

Most organizations promote SSO to improve user-friendliness and provide for better user-experience. Determine however if you want SSO for your most classified IT-assets. SSO can provide access to a multitude of IT-assets due to a security breach in only one of the IT-assets. A best-practice is to grant access to IT-assets based on authentication level; if you authenticated using basic authentication, SSO will only grant you access to IT-assets requiring the same or a lower authentication level; not to IT-assets requiring “high-level” authentication.

The SSO-provider needs to be verified and trusted before you can hand over authentication to that provider.

Authorization
Don’t tie rights to IT-assets directly to user identities to avoid high maintenance costs, inflexibility, and lock-in of users. A good design-principle is to use a form of Role-Based Access Control (RBAC) to decouple authorization. Use attributes such as organizational units and/or job titles that do not change frequently over time as intermediary layers in the authorization model. Assign rights in IT-assets to entities in this layer (e.g. organization unit and/or job title) and vice versa assign user identities to these intermediary layer(s). Design the authorization model per identity type (customer, employee, supplier, etc.).

Base authorization on the work/function someone or some organization needs to do; no more, no less. Avoid “super-users”; usually management and/or IT-staff that have gathered much more privileges over time than they’re entitled to. Increase security by assigning more than one role to the various steps in sensitive processes thereby preventing one user to be able to execute the process entirely.

Logging and monitoring
Functionality and processes in an SOA are spread over different loosely-coupled components. Some logging and monitoring needs to be executed on a higher level than on that of an elementary service; but rather on composite service or process level. This gives rise to the need for a central logging and monitoring component that is able to combine and correlate decentral logs and enables monitoring on process-level. The Wire Tap pattern can be used to publish logs, sensors, and other types of messages from services and middleware to the central monitoring component. Notifications can be managed and implemented separately of the logging and notifications can be published by this central monitoring component. Note that this requires synchronization of date and times of the several components that are managed to enable correct correlation. Determine for every service if it is allowed to continue operation in case the central monitoring component fails. Is it e.g. allowed from a security point-of-view to use decentral -localized- logging and monitoring in case the central monitoring component is down?

“Hard” security
A best-practice is to divide security in a number of layers. Chart possible vulnerabilities, threats, and corresponding principles and guidelines to counteract them. This approach results in a more effective and efficient security. Examples of such layers are: network security, platform security, application security, integrity & confidentiality, content security, and mobile security. Examples of principles and guidelines are applying compartioning (network security), to have a central list of allowed and non-allowed file extensions for inbound and outbound traffic (content security), and the use of hardening (platform and application security).

Oracle’s direction
In case of Oracle’s SOA product stack (SOA Suite 11g) security is externalized from almost all products and can be applied using policies. These policies can be configured in a management console and reused by processes and services that are packaged and deployed as SCA composites and components. These policies are based on standards such as WS-Security. Oracle Service Bus (OSB) contains security functionality though. As stated in OSB’s SOD: “The ability to attach, detach, author and monitor policies in a central fashion will be extended to the Oracle Service Bus (as it is has been extended to all other components in the SOA Suite 11g).” In any case you can already secure OSB projects using OWSM.

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

Vision on Enterprise architecture and BPM
In the past, Oracle was only talking about tools, tools and tools. Well, maybe sometimes about people: the people that administer the tools and the people that develop applications using the tools…
This year, there was an encouraging number of presentations from Oracle about Enterprise architecture, BPM methodology, and reference architecture. I guess this is the positive influence from the BEA merger; a lot of people in BEA came from Fuego, Flashline. They have a natural focus on business and architecture.
Apart from the presentations, Bob Rhubart organized an Enterprise Architecture meet up where I had a great time and met interesting people (architects) from both Oracle and other companies.

New features in the upcoming BPM Suite
Unfortunately, I missed the hands-on lab where you could test drive Oracle BPM 11g. Luckily, I got a great demo at the demo grounds from Mateo. The upcoming version is completely integrated in the SCA fabric. Instead of having screen flows, the human task service is used. Oracle Business Rules is nicely integrated into the product and everything still looks and feels the same as the previous (Eclipse) based version. The coolest part though, is the web client. I think it is called the composer. It is a web based application, built using ADF and flash,
where business users can either create new processes or change and edit existing ones (templates) that are delivered by IT. This makes handing over business processes from Business to IT and back much easier. Giving both the tools and information they need. I can’t wait to get my hands on this!

Hands-on labs
Another nice feature of Open World are the hands-on labs. They give offer a nice introduction into new features, and give you a chance to talk to the product managers at the same time. This year I liked the lab about connecting OSB to Oracle E-Business Suite the best. It showed me how easy it is to deploy the JCA adapters into Oracle Service Bus. The way this is done is surprisingly simple: you create the adapter, in this case the E-Business Suite adapter, in JDeveloper. Then you create a project in OSB, import the XSD and the WSDLs and you are done!
It sounded very awkward when I first read about it, because you need to develop the adapters in JDeveloper and then move over to the OSB console to deploy them. But because all you really need is to upload the WSDLs and the XSDs, this is a nice solution until OSB gets integrated with JDeveloper and SOA Suite 11g. That is another thing I look forward to: the new version of the OSB…

Meeting people and being back in San Francisco
Apart from the content, the conference is about meeting people. There are a lot of people you can meet, talk to and connect with. I love re-uniting with everybody. There are numerous occasions where you can do this, targeted at different groups. At the demo grounds you can talk to Oracle people, but also other vendors. I had a really interesting conversation with the people from Mulesoft.
Apart from that, there are the social events: there is a blogger night, SOA Partner Council event, Ace dinner and to top it all: the appreciation event tonight. I look forward to that: the rain from yesterday has stopped and it promises to be a great party!

So far, this trip has been very inspiring and worth while.