Interview with Mark Blowers-Ovum Butler’s Group

’Whichever route you choose, remember that EA is a path, not a destination. EA has no value unless it delivers real business value as quickly as possible. One of the most important goals of any EA is to bring the business sides & the technology side together so that both are working effectively towards the same goals”. ( ).

We interviewed Mark Blowers from OVUM Butler’s group to capture his views on Enterprise Architecture.

About EA:

EA has several definitions and many have their own interpretations. How do you view EA from an educational institution perspective?

An approach which can help educational institutions understand the current situation and provide agreement and visibility on the way forward. Educational organisations are increasingly finding funding coming under pressure which leads for the need to look for efficiencies, which is difficult if you don’t have the visibility and understanding of where you are now and can not compare alternative solutions.

’EA is interesting in theory and hard in practice ‘’ what’s your opinion regarding this statement? Can you please suggest some best practices that are applicable for educational institutions?

Historically many organisations have not gone about EA in a pragmatic way focussing on the initiative rather than the deliverables for the different stakeholders. would suggest that EA is an iterative process with frequent delivery of useful viewpoints.

Effective EA:

Measure and communicate success

Leadership role in strategy and service delivery

One architecture multiple views

Iterative creation of enterprise architecture

Development of a framework

Supported by use of intelligent tool

Key considerations:

Senior management support

Focus on speed of delivery

No need to model the entire enterprise

Be aware of people aspects

Allow solutions without architecture input

Drivers for EA

What are the main operational, tactical and strategic adoption drivers for EA?

Main drivers include:

Better strategy execution

Improved decision making

Ability to manage change effectively

Faster solution delivery

Evolve simpler environment

Do you see a shift in EA projects becoming more business focussed rather than IT focussed?

Not sure a shift. Successful EA focussed on both enterprise and IT – deliverables (viewpoints) are applicable to both. Although many organisations start from an IT perspective as that is easier and evolve to include the enterprise.

EA projects are strategic in nature rather than to fulfil short term needs. Do you agree to this statement? Have you come across any business that has implemented EA to fulfil short term goals?

No. EA is strategic in nature but this does not preclude it from being used for tactical projects. Number of instances where EA used to identify cost efficiencies.

EA adoption

How do you see the relevance of EA for educational institutions? Do you see a need there?

Most educational institutions (especially higher education) are large enterprises with the same issues as businesses, therefore EA very applicable. Would envisage that there are the same requirements.

Can you provide an example on how an educational institution has benefited from EA?

Have public sector examples but not come across an educational example.

How do you see EA adoption in forthcoming years to come? – Main challenges and drivers?

Recent Ovum survey indicated that ¾ of organisations have adopted EA. Expectation is that adoption will continue and that EA will become an accepted, and more important, a relevant approach within most organisations.

Timetabling and Resource Scheduling workshop-Birmingham

Last November, I had the opportunity to attend the JISC Timetabling and resource scheduling workshop in Birmingham. This event had several participants that include vendors like CELCAT, Scientia and Serco Facility CMIS. On this event, The Academic Registrars Council (ARC) timetabling practitioner Group and the Association of university Administrators (AUA) Space Management Special Interest Group (SIG) were launched. The main role of ARC practitioner group is to conduct periodic meetings, discuss the sector wide issues with respect to timetabling, analyse system and processes,exchange information through the mailing list (JISC-TIMETABLING@JISCMAIL.AC.UK).

Zeb Nash from Oakleigh Consulting Group presented the findings of the timetabling and resource scheduling study. The study focussed on common approaches to timetabling and resource scheduling across various institutions, identified the challenges, issues and considers the outcomes as a foundation for success to meet the challenges and issues. The main objectives of the timetabling study were based on the relation between curriculum development and timetabling. As a part of the study eight regional workshops were organised where 59 institutions and 95 participants were invited. Interviews with system suppliers such as CELCAT, Scientia were also conducted which identified student expectation, complexity of curriculum, culture and strategic ownership as its main drivers.

The main findings of the study include,

  1. No two institutions timetable in similar manner
  2. ‘Student led timetabling works better than staff led one’
  3. Developed four model approaches to timetabling based on the three main activities in timetabling(scheduling, requirements identification and location allocation) which are managed either in a centralised fashion or in a distributed manner

The most significant challenges impacting timetabling process were issues from

  1. Technology- A mammoth task in implementing a timetabling system with required functionalities
  2. Process- Dependent on the inputs from other connected processes such as Enrolment, Curriculum management processes
  3. People – People adapting to change (changing corporate culture) in an institution.
  4. Policy- Challenges in connection with conflicting priorities in institutions like teaching staff preferences regarding availability, efficient use of locations in producing a ‘student-focused’ timetable.

Following topics/ areas for discussion were discussed towards the end of the event

  1. Good timetabling policies adopted across institutions
  2. Strategic influence to timetabling /not considering it as a secondary activity
  3. Space charging issues
  4. Where should timetabling sit?-Needs championship at senior level
  5. Regular analysis on ongoing change requests and ways of managing them.
  6. Improved use of technology, usability/capability of systems must be highlighted in institutions
  7. To see answers from different institutions for questions like -‘Is your timetable meeting your drivers? If so, how efficient is it?

Finally, it was recommended to consider Timetabling as a strategic issue rather than an operational exercise.

Unified Modeling Language (UML)

UML is definitive software modeling language. This emerged in the mid 1990’s with the standard driven from the Object Management Group TM or OMGTM. It is a graphical language with a set of semantics and rules. UML was developed to reduce the communication inefficiencies between various stakeholders within a project .The rules are explained in a form known as Object Constraint Language (OCL) which uses simple logic for specifying the properties of a system. UML has integrated the notations from the union of Booch method, the Object-modeling technique (OMT) and Object-oriented software engineering (OOSE) into a single, common and widely usable modeling language.


The goals in the design of UML were
•To provide an expressive, ready- to-use visual modeling language that can develop and exchange meaningful models.
•To provide a formal basis for understanding the modeling language and support higher-level development concepts.
•Integrate best practices and methodologies.

UML defines nine graphical diagrams such as Class diagram, Use-Case diagram, Behaviour diagram (Interaction, Sequence, and Collaboration diagram), Statechart diagram, Activity diagram, Implementation diagram (Component, Deployment diagram) where not all are used in practice.

Class diagram -It is developed through Use-case, Sequence and Collaboration diagrams. It represents the class structure of the system with relationships between classes and inheritance structure.
Use-Case diagram-It is a scenario-building approach in which we model the processes of the system.
Behaviour diagram-It comprises three divisions such as Interaction, Sequence, and Collaboration diagram. Sequence diagram are mainly used in dynamic modelling situations. Collaboration diagram is all about showing in a scenario how objects interrelate in a system and Interaction diagram is used to examine the behaviour of objects within a single use case.
Statechart diagram – It’s also used in dynamic modeling situations that specifically describe the events occurring within a single object in a system.
Activity diagram- It is used to model the entire business process.
Implementation diagram shows the implementation phase of systems development, such as the source code and runtime implementation structures. It comprises the component diagram which is usually represented as a graph that models the physical components such as the user interface part of the system and Deployment diagrams are used in conjunction with the component one in representing the physical modules in a system.

The choice of what models and diagrams one chooses and creates entirely depends on the problem scenario and how the corresponding solution is shaped to it. UML combines best techniques from data modeling, business modeling ,object modeling, and component modeling concepts. It can be used with all processes, throughout the software development life cycle, and across different implementation technologies. On the other hand, the main disadvantage was that it does not support other diagrams to be used in it like the data flow diagram (DFD) as they do not fit into the object oriented paradigm. Also, the comments from various blogs and reports read out to be ‘’Advanced concepts of UML are well documented in theory but little formulated in practice’’. Finally, the interesting fact on UML graphical notations is that it can define a model itself in addition to system’s components; this is called as a meta- model. It does provide a single, common and definitive statement of the syntax and semantics of the elements in the UML.

A brief guide to the Standard Object Modeling Language (2nd Edition) by Martin Fowler and Kendall Scott (Addison Wesley, 1999)

Microsoft Oslo

In October 2008 Microsoft first presented Oslo as their new modelling platform in the Professional Developer’s conference to the public. Oslo is the code-name for Microsoft’s unified modeling platform developed to empower non developers to build distributed applications. Initially, it aimed at developing a visual and repository tool for creating models and finally emerged as a programming language.

It can be considered as a
• New language that can create your own Domain-Specific Languages (DSL),
• Visual modeling tool and
• Repository for models that we build.

Microsoft promised that Oslo will be the unified basis for “future versions” of Visual Studio, Microsoft System Center, BizTalk Server and Microsoft SQL Server. “Oslo” is slated to have “visual modeling and composition tools, a foundational repository built on SQL Server 2008 for managing application metadata, and a new, declarative modeling language to enable interoperability of models between tools and domain-specific modeling notations (Microsoft subnet blog). The aim is to increase the communication between developers, modellers, business analysts and decrease the time involved in designing complex projects. It is a tool for working with data and creating data. Several articles in the e-week reveals that it breaks down the barriers to sharing models between projects and enables stakeholders involved to utilise the other resources.

After the launch of Microsoft Oslo many experts posted questions such as, ‘‘Will Microsoft’s Oslo Support UML (Unified Modeling Language) and BPMN (Business Process Modelling Notation)?’’ with answers from the concerned people,’’This tool enables users to capture domain knowledge in domain specific views and will be useful for more advanced programming, such as enabling the development of BPMN workflows and UML services.

Finally, I would like to quote the article,’ Where is Microsoft Oslo from SD Times blog, that recently, Microsoft is whittling away from the development of the designing tool- Oslo, which is quite disagreed from the developers.

More resources can be found at

Soft Systems Methodology (SSM)

Soft Systems Methodology (SSM) is a cyclic learning system which uses models of human activity to explore with the actors in the real world problem situation, their perceptions of that situation and their readiness to decide upon purposeful action which accommodates different actor’s perceptions, judgements and values (Checkland, 1984, p.98).
We interviewed Stephen Powell from the coeducate project to identify the art of producing activity models in SSM in reality.

(1)SSM as an inquiring process, in turn established the ‘hard/soft’ distinction in systems thinking. Do you agree with this statement?
My opinion is that, it is a process of enquiry closely aligned to action research (i.e.) identification of problem, where the solution is enhanced by people working in itself. It enables people to identify, come up with the solution process to solve the problem themselves at some stage.

(2)The rules of SSM are always applicable to high level mapping. What’s your view on this?
I don’t see SSM as a mapping exercise. My view with a bit of experience in co educate project is as a problem solving one.

(3)Regarding the adoption and use of SSM; level of exposure is considered as a major factor and many feel it’s time consuming too. What’s your opinion on this?
Yes, I agree with this statement. Definitely it’s not a one man show. Adoption and use becomes easier when working in groups. In real world, we need to be pragmatic and practical. Following the seven steps of SSM rigidly might be time consuming.
I’d like to share my experiences with SSM like,
Initially, understanding the idea of complexity of the problem was a big milestone. Through interviews, focus groups we identified the exact location where the problem sits. We then made choices on discussions, interactions after the root definitions were framed up. Then identified, the biggest strength of SSM is that it’s practical usability in a wide range of situations by people without technical background.

(4)People taking baby steps in modelling, do you recommend soft side of modelling at the start or the hard bit like the Enterprise Architecture Modelling?
Yes, definitely I will recommend SSM to be the starting point to understand the problem scenario and then migrate to the hard side of the modelling spectrum. The main advantage to start with the soft side is that, SSM as a methodology offers good facility where the intensity of the problem can be compared at each stage.

(5)What are the advantages of SSM considering that it has played a good role in the co educate project?
I feel it’s not hard, simple to understand. The harder bit is the interactions with the people and formulating the problem scenarios. It does address some questions at the end by analysing the problem. I feel Enterprise Architecture modelling is not really involved in solving a problem. It’s a diagrammatic depiction of the problem.

References and Resources
(1) THE ART OF MODELLING IN SSM by Dr Mark P. Mobach,Prof.dr Jos J. van der Werf,Prof.dr Th. (Dick) F.J. Tromp
(2)Soft Systems Methodology in Action by Peter Checkland and Jim Scholes.

The Problem with Modelling or Modelling Problems –Session in JISC CETIS Conference 2009

The focus of the modelling world is now shifting from a purely technical perspective to a more holistic approach. Due to increased interest in modelling; the necessity of using comprehensive modelling tools has become fashionable now. The session answered the question: Why modelling?And suggested different ways of modelling

  1. Modelling problems in all situations –SSM (Soft Systems Methodology)/SODA techniques
  2. Modelling complex situations , dynamic systems modelling
  3. Enterprise architecture route to modelling
  4. Modelling organisations as systems –VSM(Viable System Model)

Certain issues have been identified such as

  1. We’re using a number of blueprinting approaches to simplify the work, but do they do their job?
  2. We need a model to be shared between IT and business people and sometimes we prefer to use a flow chart as it satisfies the purpose instead of complex modelling languages such as UML, BPMN, Archimate’’
  3. Models can be quite difficult to use/ or do not give a precise answer to many of our problems
  4. How can we choose an appropriate model for our project? Once we’ve chosen, can we use it as a basic model and re use in future?
  5. We can draw ‘’as-is’’ and ‘’to-be’’ scenarios for considering the institutional priorities/capabilities.

Certain Key findings for the above listed issues were

  1. A model for whole organisation doesn’t exist. Once universities realise that the Enterprise Architecture approach is beneficial, it then becomes necessary to use the skills of an Enterprise Architect. However most institutions do not have access to such a person.
  2. It’s important to first identify the level of abstraction required, who is it for, why are we doing it, etc and then to identify the different ways in which people communicate using the modelling world. Only then can the decision be made on how to proceed.

It was a very good session in the JISC CETIS Conference headed by Oleg Liber. I felt it’s a good theme to look in to the future and explore the different ways of Modelling.

The general outcomes were

  1. Need to manage complexity and sheer volume of information
  2. Trying out a number of methodologies like SSM.
  3. Increased interest in process modelling

Finally,Model is the thing which will be used in between to understand Business and Code. Model is nothing but a description of a domain. It can be a System Domain like UI/Service etc… or can be a Business Domain like Finance/HR etc… (Eric Rosh ‘s SOA blog)

JISC FSD Programme

The JISC FSD programme aims to highlight the role of the current IT infrastructure in colleges and universities, the challenges faced by it and how effectively and efficiently it can be used. One high level technique suggested is to take the Enterprise Architecture approach to managing the processes, information and systems that make up such an infrastructure. A particular route within EA is to design and implement a Service Oriented Architecture, which can help senior managers in the HE/FE sectors to achieve a flexible and agile IT environment.

The FSD programme runs from the 1st July 2009 till 1st march 2011, and is part funded from two sources: the HEFCE/HEFCW capital funded programme to support IT infrastructure and JISC’s core budget. More information about the programme structure can be found at

The FSD support and Synthesis is comprised of

· JISC-CETIS for technical development support

· JISC Info-Net for synthesis activity

· UCISA and ALT to liaise between the Strategic Technologies Group of the FSD and the wider community and supplier engagement

The first activity in the JISC FSD Programme is the establishment of the Strategic Steering Group (STG) that brings the representatives from different educational institutions; explore different flexible ways of providing academic and administrative services. The STG will have a first meeting on October 2nd in London. More details on the FSD programme, the STG and the meeting are available at A comprehensive, high level overview of the STG’S activities, drivers and benefits is provided by a JISC flyer on the topic.

Finally, JISC aims to act as an impartial facilitator by between the suppliers (open source applications providers of administrative and academic systems) and customers by running a series of workshops, maintaining good engagement with suppliers by discussing the barriers and possibilities for flexible and shared service provision, and identify and prioritise the requirements for solving them.

John Zachman -Lifetime achievement award

Zachman is being recognised for his contributions to Enterprise world.

John Zachman receives a Lifetime Achievement Award and delivers a great speech.The award was presented at the CAEAP Summit on June 20, 2009 in Los Colinas, Tx.

I enjoyed the entire set of informative videos of the presentations given at the Centre for the Advancement of the Enterprise Architecture Profession (CAEAP) Summit.

Hats off !! Congrats for your achievement.

Enterprise Architecture

What is Enterprise Architecture?

Enterprise Architecture is an important element in any organisation because it addresses the principles, methods and models used in designing the organisational infrastructure, business processes and information systems. Organisations are now starting to realise the importance of Enterprise Architecture when adopting new business strategies. Enterprise Architecture is about understanding all of the different elements that go to make up the organisation and how those elements

Why is it Important?
Enterprise Architecture is a coherent description of products, services and processes within the organisation. The degree of usage varies between organisations. As organisations are now tending to focus on strategy and to introduce new business models that require the complete integration of technology, processes and the business itself, organisations are starting to understand how Enterprise Architecture can:
• Efficiently align business (processes, strategies, goals and so on) with technology (computer applications, data controlled by processes, etc )
• Provide control over Information Technology costs.
• Reach the expectations of customers (supply versus demand).
• Create a strategic vision for the whole organisation, particularly now that Information Technology has become such a powerful force, which is bringing about many fundamental changes.
• Manage and control organisational changes.
• Easily adapt to changes in meeting customer demands.

The need to move toward an Enterprise Architecture approach becomes more important when the current architecture stops supporting the organisation, or when the organisation starts to modify its current architecture. Also, the recent trend of migrating towards new modelling tools and frameworks has been increasing steadily.
Regarding the usage of Enterprise Architecture, such as how, when and to what degree it should be used by an organisation, JOHN A. ZACHMAN, in his “A Framework for Information Systems Architecture”- (IBM Systems Journal, vol 26, no 3 1987), states: ‘’Without a predetermined structure in the development of organisation-wide information systems, all efforts will lead to chaos and disintegration of the organisation’’.

What are the advantages in Using Enterprise Architecture?
The advantages for any organisation in using Enterprise Architecture are:
• Increasing controllability of organisational change.
• Clarifying connections between different domains.
• Offering a tool for improving business ICT (Information and Communication Technology) alignment.
• Increasing efficiency of the organisation’s Information Technology function.
• Minimising investment risks by reducing the complexity of the Information Technology infrastructure and increasing its flexibility.
Finally, although Enterprise Architecture is not a revolution in itself, it does offer a different perspective on the management of organisations and provides an effective execution of change management. However, it still all depends on how the organisation interprets Enterprise Architecture and how it is used.

JISC Timetabling Workshop -Manchester

I attended the JISC Timetabling workshop on 14th October 2008 in Manchester run by Oakleigh Consulting Limited, appointed JISC to run the study on timetabling and resource scheduling. This workshop included participants from HE and FE sectors. The workshop was divided into three main sessions. The first and the second covered the general positioning and the process model in timetabling whilst the third concentrated on drivers to it. The common processes involved in timetabling, problems in the current processes, how current and re-engineered processes are supported by technology and finally the actual links between timetabling, resource scheduling, and curriculum delivery and planning and course delivery were also discussed.

One of the sessions covered the position that most institutions take with regard to the three high level approaches/drivers to timetabling. The approaches/drivers are:

1. Distributed scheduling and requirements identification –central location allocation

2. Distributed scheduling and requirements identification and allocation of locally ‘owned ‘ locations – central location allocation of ‘high demand’ pooled locations

3. Distributed requirements identification –central scheduling and location allocation

The three high level approaches which are applicable to both central or distributed allocation, include factors such as depends on efficiency, curriculum complexity, locus of control, culture , student satisfaction (retention perspective), physical layout(environment) and so on. Most universities fall somewhere between the second and third but generally aim for the first one.

The workshop included a lot of participation from the audience. We were divided into groups to answer some scenarios on timetabling and resource scheduling. A sample is given below.

Scenario: Cross institutional delivery is becoming increasingly common.

Question: What process improvements can be made in this area to achieve benefits such as production of a single timetable for students, effective transfer of information etc?

Answer: Cross institutional delivery started in the FE sector. As the main challenge is the liaison between people and planning, then course development and resource planning must go hand in hand.

Oakleigh Consulting Services have published their final report with the ultimate deliverables from the timetabling study .