I have taken a SOA Readiness Assessment from BEA and got a customized SOA Benchmarking Report for Økonomistyrelsen. The Assessment is based on 6 profiles, which can be understand as SOA-maturity levels. The 6 profiles are No Adoption of SOA, Ad Hoc Adoption of SOA, SOA Approach Defined, Division-Level Adoption of SOA, Enterprise-Wide adoption of SOA and Optimized for SOA. The different profiles/maturity-levels have different charistiscs according to the 6 domains (areas) Business Process & Strategy, Architecutre, Building Blocks, Projects & Applications, Costs & Benefits and Organisation & Governance.

Økonomistyrelsen have the profile Ad Hoc Adoption of SOA, which is the second lowest maturity level. We have a relative high score on Organisation &
Governance and Architecture. But we have a low score in the domains of Building Blocks, Projects & Applications and Costs & Benefits. This conclusion is not a surprise for us.

The Assesment altso gives a lot of guidelines and Best Practices in the 6 domains or areas, which we can use practically for moving to the next maturity level.

Therefor is the SOA Readiness Assessment from BEA a good tool for measurement of SOA Readiness or Maturity with good practical guidelines for moving further in the SOA-transistion. Another plus is that the Assesment is generic and not specific focused on technology from BEA.

Vejdirektoratet have developed a Webserviceguide with the purpose of easy development of Webservices. The document can be downloaded here.

The guide also contains knowledge and guidelines about Business Modelling, Requirement Specification and design of WS.

It is interesting to see the that the Business Modelling is done with Use Cases and Activity Diagrams, though SOA and Webservice are procesoriented. Interesting point, not?

Yesterday I participated in a seminar about SOA and BEA AquaLogic ESB. One of the presentations was about BEAs SOA Domainmodel with 6 domains with best practices in organizational, financial, operational, design and delivery aspects:



The six distinct domains are interrelated and interdependent and essential for a successfull SOA-implementation. One of the most important domains are governance and management, which is also a important aspect of EA. The whitepater about the Domainmodel can be downloaded free from here.

On http://contact2.beasys.com/bea/www/soa_benchmark/login.jsp?TRK=1&LNG=AMER&PC=10SOSO3 can your organization take a SOA Readiness Assessment and after 24 hours you can get a customized Service-Oriented Architecture Benchmarking Report. It is very interesting and I will make one for Økonomistyrelsen.

Some of the other interesting aspects was:

- Importance of combining SOA with EA.
- The first SOA-project (pilot-project) will be very costfull and timeconsuming and the benefits will first be achieved after 2-3 projects. Therefor is SOA an investment in the long term.
- The BEA AquaLogic ESB also consist functionality for Security based on SAML 1.1, digital signatures, SSL etc. Moreover is SOAP/HTTP-messaging done with WS-I compliance.

ESB (Enterprise Service Bus) is the latest generation of application integration technology, succeeding traditional integration brokers such as messaging middleware. The ESB manages messaging, transformation and routing of services.

Selection of a proper ESB-product have relevance for all organizations working with SOA. In this context it is very interesting to follow Network Computings review of the most prevalent ESB-products. Though the review-proces will end on the 16th march, you can already see some of the review-results under the section Rolling Product Reviews here.

On tuesday I am participating in a seminar about BEA Systems ESB. You can see the programme and perhaps join here.

One of the most important task in EA is to design principles. There is much discussion on how many principles, their should be designed. I have seen examples of organizations with 100-150 principles and some have just used the 5 from VTUs Haandbook. The dilemma is, that few principles are very generally and abstract and therefor difficult to use practically. To many principles is difficult to manage and there is therefor a risc for that they just become an another method-book and ends in the shelf.

Økonomistyrelsen have designed following 10 principles according to the EA-vision and the business and technical drivers:

1. Solutions must be based on commen public standards
2. Data must be maintained at one place and reused cross the organization
3. Security must reflect legislative requirements, commen public standards and business needs
4. IT-investments must be optimized according to the EA-view and documented in business cases
5. IT-costs must be documented with a common method
6. Buy standard solutions before building inhouse solutions
7. Business functionality must according to business needs be capsuled as scalerable services
8. Integration between the solutions, internal and external, must be done with Økonomistyrelsens integration architecture
9. Solutions must be designed in layers and with modularity
10. Solutions must be documented according to Økonomistyrelsen documentation standards

I think that the number is suitable for our organization. They are easy to manage and remember. F.eks. is it relative easly to identify EA-initiatives/-projects out of the principles and they are relatively concrete for more practically use.

I have seen other organizations just using the 5 principles from the VTUs Handbook and for every principle, designed 5-8 EA-politics. These EA-politics are more concrete and can f.eks. be used as technically open requirements.

Therefor is my conclusion, that the number of principles is depending on the EA-proces, needs and the context. But the guideline must be to design fewer principles.

One of the prioritized EA-projects is a Common BusinessIntelligence (BI) Architecture in Økonomistyrelsen. Økonomistyrelsen manages SKS (Statens Koncern System), SB (Statens BudgetSystem), SLS (Statens Løn System) and NS (Navision Stat) and the scope of the project is these systems. These 4 systems have a long and complex history and the BI-Architecture has been designed very different without the EA-view. The 4 systems use platform and Reporting-facilities from SAS, Crystal, Navision and inhouse-development. The different BI-systems have problems with drift, the users can not use the facilities, low usability and large costs to vendors and consulants because of the complexity and proprietary technologies. Others problems are different modelling-techniques, datamodels and . Some data are on local Datawarehouses and some data are transported in flat files on cd-roms.

The EA-projects goal is a common BusinessIntelligence (BI) Architecture in Økonomistyrelsen and we are communicating with the Business-units, vendors and consulting firms. It is a very exciting and ambitious project with many interests. Moreover are the requirements very big because of the assurance. F.eks. are the BI-systems used to check about 300.000 govermental employees paycheck and to manage the whole accounting of the Danish state.

This was my first week at Økonomistyrelsen. My mentor was on vacation, so I used most of my time to learn about the organization, the processes and the EA-work. It was very interesting to read about the practical EA-work. The EA-work has been done according to the Handbook for IT-Architecture for Danish e-goverment published by the Ministry of Science, Technology and Innovation (Haandbog i IT-Arkitektur for digital forvaltning).

The practical EA-work have been done by EA-Management Plan and establishing of the EA-programme, maping of the main business processes, tasks, systems and organizational entities. This has been done by workshops and interviews. Then formulization of the architecture vision with 5 goals, design of 10 principles and
GAP-analysis have been done. Task plan with the EA-projects on the basis of the GAP-analysis was developed. For all the projects, the Cost/Benefit was evaluated and Requirement Catalogue with shared requirements with Reference Architecture, standards and guidelines for the different platforms was produced. The output of the whole work was a prioritization of the EA-projects.

It was also interesting to see the organizational aspect of the work. This aspect have been managed with roadshows, communication activities, EA-Ambassadors and workshops.

Today is the birth of my blog. I was inspired by my colleague Pelle Braendgaard at KMD AS, where he was J2EE-consultant on a project I also was involved in.

My aim with the blog is to share my ideas and thougths about my interests. My main interests are Enterprise-/IT-Architecture, strategy, planning, management/governance and outsourcing. All this stuff is of course in the field of IT.