We are working with Common methods for Requirements Specification. A part of this is a process for finding non-functional requirements for systems. I have based this on our EA-work. The structure of finding the non-functional requirements is:


Our EA-vision and principles should be discussed, which will result in non-functional requirements for the system. The case is same with our reference architecture and common architecture requirements. The reference architecture shows the preferred modules and layers with guidelines for our future systems, which will result in non-functional requirements for the system. The common architecture requirements are generic requirements, which should be discussed for finding specific non-functional requirements for the system.

The EA-vision, principles and reference architecture should be inserted directly in the requirement specification of large systems. Moreover should they be presented to the vendors for asking them for their solutions.

Producing architecture documentation for a system, is an obligatory discipline in our Common developmentprocess based on RUP. In the discipline the project should see their system based on our 5 architecture views after performing a global analysis. All the architecture thoughts and decisions should be documented. This will of course result in non-functional requirements for the system.

We will document requirements for the functionality of the system by Context diagrams, Use Cases and functional requirements. All this will of course result in non-functional requirements. This process should be done by reviewing and discussing all the actors, Use Cases and functional requirements according to our 10 requirement types. Requirement types is a device to help you to find non-functional requirements and act as a checklist inspired by the Volere-process. Examples of requirement types are Look and feel Requirements, Security Requirements, Maintainability Requirements etc.

Last week I participated in a meeting with a presentation by Lars Frelle-Petersen, who is head of the Administrative Political Center at Ministry of Finance and leader of the Digital Taskforce. Lars Frelle-Petersen represented his role as leader of the Digital Taskforce and talked about technological scenarios in context of the digitalization of the Danish public sector.

Some of the points were the new modernization programme, more common projects and cooperation a cross the public sector (det faelles offentlige), big ambitions about digital citizen self-service (digital borgerbetjening), the citizen portal, common components, and the standardization and architecture work. The generally theme was much more focus on efficiency and achieving business benefits.

A new modernization programme
This is a new programme with the purpose of integrating business and it in the public sector and is assumed to be ready primo 2007. The vision of the programme is "A simple, efficient and serviceoriented public sector". The vision should be achieved by initiatives as for ex. flexible public management, successfully public innovation, an engaging and efficient working place, measurements and follow-up on results, the digitalized public sector and better handling of citizens and businesses. I think this programme is very interesting, because it consist a lot of business and organizational initiatives and aspects, which are very important for getting more benefits of the digitalization (based on EA and SOA) of the Danish public sector.

More common projects and cooperation a cross the public sector
This cooperation a cross the public sector will be more deep and broader in the near future. The standardization of the sectors (sectorstandardisering) will be stronger, which needs a stronger coordination and more common solutions. The common digitalization projects a cross the sectors will become closer to the core business of the institutions as for ex. with the citizen portal, virk.dk and common user role management (faelles brugerstyring).

Big ambitions about digital citizen selv betjenining (digital borgerbetjening)
The background is e2012, which is the target of the globalization board (globaliseringsraadet) for 2012, where all relevant communication between the public sector, private sector and citizens must be digitalized (=almost full digitalization). This will be voluntary for the citizens and an obligation for the private sector regarding sending digital documents, applications and reports etc. Some of the initiatives for achieving this is the citizen portal and a new strategy for modernization with focus on digitalization and citizen self-service based on processes across the sector.

The citizen portal (borgerportal)
The new citizen portal will be a portal with the vision of collecting all the services from the relevant public institutions, so the public sector can act as a whole (one single face) regarding the citizens. In 2012 all the relevant institutions should provide there services trough the portal. The concept is:



Common components
There is a need for more common components across the public sector and a better concept of decision making regarding this. Some of the components will be user role management, more functions to the digital signature, forms server (blanket server), document box, payment solutions, NemSMS etc.

The standardization and architecture work
This will be more difficult in the future. Both standardization and architecture work should be more simple, limited to the essential, much more business oriented and decentralized at the using institutions (= less central management!). The new cross-sector common initiatives and components will accelerate the need of standardization a lot. There for, there should be more focus on limits of standardization and most focus must be on data exchanging. Lars also mentioned the B103, which is the parlamental agreement of the decision bill about open standards, which will proffesionalize the standardizing work, but the focus must be moved away from the political fighting arena. My supervisor John Goetze is a big standardization-geek and have written a lot about it.

Last week I participated in OIO Arkitekturforum. It was a good arrangement with four presentations. Read about the presentations and download the slides here.

One of the most interesting presentations was about Business Process Modelling and Automation - Visions and reality by Industrial Ph.D-student Steen Brahe . Steen Brahe is employed at Danske Bank and is working with their Workflow Management System (WFMS) based on Process Choreographer, Websphere and J2EE.

Steen Brahe presented their method based on a practical case from Danske Bank. The steps in the method are:

- Textual description of the manual As-Is business brocesses with events and activities
- Modelling of the manual As-Is business brocesses with UML-Activity diagrams in for example MS Visio and then selecting the business processes, that have to be automated
- Modelling of the manual and automated To-Be business processes with UML-Activity diagrams in for example MS Visio
- Modelling of the automated and executable To-be business processes in a WFMS.

A Workflow is a detailed model of a business process as executable computer programme written in a XML-based language as BPEL and BPML. The purpose of a WFMS is to execute the Workflows after selecting relevant Webservices, information and functionality like status, statistics, performance measurement, evaluation of costing, business rules etc.

The purpose of process automation is higher productivity, quality and controlling of business events and processes with the vision of higher business agility. It moves implicit knowledge from humans and programs to explicit knowledge in Workflows. From the it-side the benefits are generic call of services in SOA, it is easy to compose services to processes and there can be reuse of services and processes a cross the organizations silos.

There are many challenges with business process modelling and automation, both organizational and technological. Some of the challenges are:

- It is difficult to understand the real business processes and the actors are often not agreeing on the process ownership
- There is a large step from a business process model to an implemented Workflow. This is the main subject of the Ph.D-project of Steen Brahe.
- Accept of the actors. They will not work in a factory. Principally should the actors only have knowledge about there own activities, but it is often useful to have knowledge about the whole business process in situation of faults etc.
- The process developers must have knowledge about business, all the technology platforms and excellent communication skills.
- The tools and standards for WFM are not mature yet. There are big challenges with test and error handling.
- It is rather difficult to find the right services and many service are not well documented
- Long response time, primary in the GUIs and not Webservice-calls

So no doubt about that this subject is difficult in both organizational and technical ways. I agree in that and more over are business process orchestration and choreography also called process enabled SOA the highest maturity level in the most SOA maturity models. Danske Bank is not so long in SOA-based process automation, though they are one of the most mature organizations in SOA in Denmark. There for there is a long way before the public sector in Denmark reach this level. More over are some of the business processes in the public sector very specific, while workflow management only focuses on generic business processes. Other difference between public and private organizations, is the law regulated business processes in public institutions and authorities and it is questionable if these complicated law based rules can be modelled as usually business rules in the WFMSs.

The 11th of May we got our EA-programme reviewed by Ph.D-student Kristian Hjort-Madsen. He evaluated our strengths and weaknesses. Some of our strengths are:

- Strong support from the top management. Some of the reasons for this is our engaged IT-Executive/CIO and the close coupling between the EA-programme and the projectportofolio management and projectportofolio board. Our advises and decisions in EA are supporting the decisions of the projectportofolio board, which is seated by Executives.
- Business oriented. Our EA-programme is based on our Business Strategy and we constantly have close interaction with the business departments. It is done formal and informal. Formal it is done with the projectportofolio management setup, where all the projects have to answer questions about the EA-principles, Reference Architecture and standard catalogue and all the it-projects are reviewed by us.
- Good documentation of the as-is business situation. This documentation was made at the beginning of the EA-programme, where all our processes, locations and concepts were mapped.
- Strong team with good mix of competencies and EA-knowledge. No doubt about that. Our team consist of a Chief Architect, two IT-Architects and two Business Architects. We all have different domain knowledge and have a common wide and up to date knowledge about EA.
- High priority and focus on communication initiatives. One of our biggest experiences is the importance of constant and focussed communication initiatives and stakeholder management. We have made a large stakeholder analysis and an EA Management and Communication programme, which is evaluated and up to dated regulary.

Some of our weaknesses and focus areas are:

- No common terminology of the EA-artifacts. This will be handled by some of your EA-projects: Development of an EA Documentation Framework and Common guidelines for documentation of systems, processes etc.
- No vision of the future to-be business architecture and the business architecture must be more proactive. Yes, this is correct and a very good vision. But we have not reached at this maturity level yet and it requires a close cooperation between the business and us, some removing of the silos, changing in culture and behaviour etc. So for the while we are just thinking in doing some business blueprinting.
- Funding of the EA-programme and employing us architects, must always be justified in the specific projects, where we always must show our value and reason of being. Our CIO is agreeing in that EA is an investment on the long term, but pointed out that we must communicate our value to the projects to him, so he can communicate the information further to the other executives and business managers.
- Silo thinking in and a cross the organization. No doubt about that…. Hmmm, maybe will SOA handle this for us?:-)