Content uploaded by Katja Penttinen
Author content
All content in this area was uploaded by Katja Penttinen on Oct 27, 2018
Content may be subject to copyright.
Lean Enterprise Architecture Method for Value Chain Based
Development in Public Sector
Eero Hosiaisluoma1, Katja Penttinen2, Juha Mustonen3 and Jukka Heikkilä1
1University of Turku, Finland
2University of Jyvaskyla, Jyväskylä, Finland
3Gofore, Helsinki
eero.hosiaisluoma@gmail.com
katja.i.penttinen@jyu.fi
juha.mustonen@gofore.com
jups@utu.fi
Abstract: Enterprise architecture (EA) was first developed in the late 1980’s and has been since promoted as a method that
can conquer the problems in aligning the business and information technology (IT). EA has been widely used in the private
and public sectors. Finnish government’s EA work started over ten years ago by customising the EA framework, method and
governance model. After new versions, the Finnish EA method (based on TOGAF) is still considered as too rigid, and full-scale
use requires quite a lot resources – and in some cases benefits of EA are unclear. In this design science research, we propose
intertwining EA into organisation’s development work. We call this method Lean EA development (LEAD) since it combines
value chain based operating model with an agile EA practice, which focuses on operational level, linking EA directly to
business demands and adding customer value. The LEAD can be adapted to any size of a target area such as to a business
domain, whole organisation or wider ecosystem. In practice, the LEAD operating model organises capabilities around the
value delivery chain. The revised architecture practice is co-operating with other functions, when developing services from
ideas to production. Collaboration with different stakeholders and architecture visualization are the most important
principles. Usage of an EA visualisation tool is a key enabler component of the LEAD, as every development target is visualised
and published continuously. This approach is operated with lean management based on agile principles and enables EA as
an important practice in the overall development. We have adopted and used the LEAD in a public organisation, one of the
largest cities in Finland, and use this case as an illustration on how the concept can be used.
Keywords: enterprise architecture, lean enterprise architecture, lean management, agile development, value chain,
visualisation, public sector
1. Introduction
The ongoing digital transformation requires many different policy areas to be considered simultaneously in an
integrated approach (Tan and Pan 2003, Janowski 2015). The need for an integrated approach, forces
governments to overcome silo-based structures and to promote cooperation at the different levels of
government to develop a whole-of-government strategy (OECD 2017). The significance of information systems
and technology is increasing, and still the need for alignment between business and information technology
remains a major challenge, especially in the public sector (Rusu and Jonathan 2017). To lead the digital
transformation to desired direction, organisations need holistic view on their information assets. This kind of
information can be achieved by the appropriate use of EA.
The Finnish government’s EA work started over ten years ago by customising the EA framework, method and
governance model. The main goal of the work was to improve interoperability of public organisations’ operations
and services. The Finnish Act on Information Management Governance in Public Administration was passed in
2011 (Finlex 2011). The act makes the use of EA mandatory, for example, in central government offices, courts
of law and cities when they conduct tasks laid down for them by law. According to the law, public sector
organisations in Finland should use the national EA method and its guidelines in EA planning and management.
Using a mandatory approach has been successful at improving the European wide interoperability (Gatti et al
2017), the Finnish national EA method, based on TOGAF (2018), is considered as too rigid and difficult to
understand. Implementation of the EA method is challenging and its full-scale use requires a lot of resources.
Practical guidelines for step by step guidance for fast and light adoption are missing. This has resulted in a
situation where the adoption of the EA method has become a problem in practice. These are the main factors
that motivate our study. The research question is: What kind of EA approach would provide better solutions for
practice?
86
Eero Hosiaisluoma et al.
First, as a solution to the above problems, we emphasise EA’s role at the organisational development. Our LEAD
method combines value chain based operating model with an agile EA practice, which focuses on the operational
level, linking EA directly to the business demands and adding the customer value by keeping the end user
services at the focus. Second, we illustrate LEAD’s practical applicability at one of the largest cities in Finland and
use the case study as an example on how the LEAD is used in a real-life setting. This sets our case study in a
constructive research approach, where the LEAD is developed at parallel with the practitioners and reflecting
the experiences upon recent developments of EA and development methods.
We first connect our study to the existing knowledge base by introducing the research background. Second, we
briefly describe the research method. Third, the LEAD is presented. Fourth, we illustrate findings from a case
study to show how the Lean EA can be applied in practice. The results form a basis for further research on Lean
EA and contribute to the discussion about the need to reconceptualize the current EA methods. Finally, we
conclude the work.
2. Research background
At the public sector, policymakers initiate EA programs to improve interoperability, enhance productivity and
improve the standard of service systems (Hjort-Madsen 2006, Janssen et al. 2013, Lemmetti and Pekkola 2014).
Despite the investments in EA, many government EA programs have performed poorly (e.g. Penttinen et al.
2018) and have failed expectations (Hope et al. 2017, Ojo et al. 2012, Saha 2009). The incapability of EA to fulfil
the promises and the challenges of EA, have been researched to some extent (Banaeianjahromi and Smolander
2016, Bui and Levy 2017, Dang and Pekkola 2017, Hauder et al. 2013, Hjort-Madsen 2006, Isomäki and
Liimatainen 2008, Kaisler and Armour 2017). Recently, the need for EA to reinvent itself has been discussed
(Janssen 2012, Lapalme et al. 2016).
We propose reinventing the EA method, using the principles of Lean and agile, to be able to answer in the
requirements of current society and market, we briefly describe the background of Lean management and agile
EA. The Lean has origins in the car manufacturing company Toyota and aims at minimization of waste in the
production process, by focusing only on things that add value (Holweg 2007, Womack et al. 1990). Later the idea
has been adapted to lean management in other areas of business (Womack and Roos 1997). The application of
lean thinking in information management means that it can be considered to involve adding value to information
by how it is organized, visualized, and represented. This enables information to flow to the end-user through
the processes of exchange, sharing and collaboration. (Hicks 2007)
Agile EA is based on agile software development that can be seen as a reaction to traditional methods, which
emphasize rationalized, engineering-based approaches (Dybå 2000, Nerur 2005). In traditional approaches, it is
claimed that problems can be fully specified and there is an optimal and predictable solution for them Dybå and
Dingsøyr (2008). This is similar to traditional EA methods, because it leads to excessive planning and modelling.
In contrast, the agile development methods address the challenge of an unpredictable world by relying on
people and their creativity instead of planned processes (Dybå 2000, Nerur 2005). There is only a limited body
of knowledge on the use of agile in EA. For example, Rouhani et al. (2008) presented an agile EA framework, the
use of agile principles in EA is researched by a survey for the EA professionals (Hauder et al. 2014), using agile
methods in creating EA deliverables and collaboration between architects and software developers is researched
with interviews (Hanschke et al. 2015). At the public sector context Gill et al. (2014) have used an agile EA
framework to develop and implement the adaptive cloud technology-enabled EA. Typically, agile EA uses
principles of agile methods such as iterations and lean thinking, and the key to successful agile EA is realising
that humans are an integral part of the system, not merely just users of the system (Bloomberg 2013). These
kinds of new EA practices require revising EA, but due to the limited research and experiences on the subject,
further evidence is needed.
3. Research method
EA is a socio-technical artifact (Mumford and Weir 1979, Drechsler 2015) and it should be studied as such.
Adopting EA in an organisation is a change intervention, which intersects both social and technical aspects in an
organisation, and successful implementation is a process of change that requires responding to social
interdependencies (Janssen 2012). The change agents are typically enterprise architects, who are managing the
whole with its interdependencies to other activities and processes of the organisation. As we have participated
in the development of a revised EA method to offer a more flexible solution to connect EA work to the overall
87
Eero Hosiaisluoma et al.
development in a real-life setting of a Finnish municipality, the researchers cannot be considered outsider
observers, but are essential subjects interacting with the organisation under study. The initial version of the
LEAD was co-created in a real setting. We used a pragmatic constructive approach in our research and two
authors worked in the case organisation as reflective practitioners (Heiskanen and Newman 1997), who co-
operate with academics and real-life practitioners to develop new, better suited, socio-technical artifacts and
EA methods.
4. Lean enterprise architecture development
The Lean Enterprise Architecture development concept is a combination of the Lean management and agile EA
practices. LEAD is a pragmatic enterprise development method that is based on collaboration and visualisation.
Those are supported by the practical Lean EA Framework (LEAF), which is enabled by an EA visualisation tool.
The LEAF guides the operational development, in which the EA visualisation tool plays an important role in
practice. All the development targets are visualised on demand.
4.1 The lean enterprise architecture framework
The basic structure of LEAF is illustrated in the abstraction below (Figure 1). The LEAF is a concrete solution to
implement the LEAD in practice.
Figure 1: The LEAF
The LEAF is divided into the following parts: Management, Value Delivery Chain and Architecture Landscape.
The Management part consists of the aspects that direct the enterprise development and motivate the change
activities. The Value Delivery Chain contains the Idea to Production value stream, which represents how services
and other development targets flow from customer-driven demands to production. A Value Stream is an end-
to-end collection of activities that creates a result for a customer. The value stream has a clear goal: to fulfil the
customer demand. The Architecture Landscape contains the actual enterprise architecture content, into which
all the artifacts are created in a just-in-time manner. The LEAF can be implemented on any applicable EA
visualization tool. Based on our experiences from public sector organisation, we have implemented the LEAF as
a reference solution in an EA visualization tool.
The LEAD is a customer centric view of the enterprise that integrates organisation’s capabilities around the value
stream model, instead of the function- or process- based approaches. This can be achieved with the traditional
business architecture approach, but LEAD is not limited to the business perspective only. Our approach is based
on several well-known methods for practical improvement of activities and processes (for example Scrum,
88
Eero Hosiaisluoma et al.
Kanban and, Service-Driven Approach) that are adapted on demand. Hence, LEAD is a practical concept. The
following examples are from the LEAD versioning IT management development method. For example, the Idea
to Production value stream (Figure 2) describes an operating model in IT management. Regardless, LEAD can be
used as a whole-of-operations model for an organisation. Then also the business capabilities (such as strategy
planning and business planning) and additional value streams (such as goal to strategy and strategy to portfolio)
are visible.
Figure 2: The idea to production value stream
Comparing the LEAD to the traditional EA development approaches, several differences can be identified. The
traditional EA development process is time consuming and resource intense, whereas the LEAD approach is
lightweight and agile. Traditional methods consist of several sequential phases (Figure 3), which is an
appropriate process mostly in the case of large organisations.
Figure 3: Traditional EA process
The LEAD is suitable also for small and medium enterprises, as the LEAD can be adopted and executed with
lesser resources and time. LEAD itself is an agile process without the big planning upfront cycle. The main
difference between the LEAD and traditional EA development approaches is that LEAD is tightly integrated into
holistic enterprise development, not solely taking the architecture and operational viewpoints. The LEAD
approach is focused on delivering the business outcomes that are based on the strategic goals and the customer-
driven demands. The LEAD also incrementally produces new data into Architecture Landscape as new
development targets flow through the value delivery chain (Figure 4).
Figure 4: LEAD approach
The LEAD architecture landscape is a combination of the traditional EA’s current “as-is” and target “to-be”
architectures. The architecture landscape provides the current situation of the organization’s business services,
processes and applications, and planned new services etc. With the LEAD, distinct as-is and to-be architectures
are not maintained as separate entities in large scale. This makes the architecture modelling work faster and
more efficient. Only some specific development targets can be visualized in distinct as-is and to-be views if
needed. Methods that can be applied are e.g. the Open Group Architecture Framework (TOGAF 2018) and the
ArchiMate modeling language (Open Group 2016). In the LEAD, the EA content is produced and delivered
89
Eero Hosiaisluoma et al.
continuously into the Architecture Landscape. In addition, portfolios and roadmap can be adjusted according to
changing conditions continuously. This approach enables faster development cycles, shorter time-to-market,
better reactivity and productivity compared to conventional approaches (Figure 5).
Figure 5: Conventional EA work compared to LEAD approach
The applied Lean and agile principles encourage to avoid unnecessary big design up-front and redundant
planning activities. However, without planning and governance the organisation’s Architecture Landscape
would, according to law of entropy, drift into chaos. It is reasonable to inspect the new requirements against
the existing Architecture Landscape, putting more emphasis on managing the alignment with mission, vision,
strategy and architectural principles, while learning from experience, as new services are deployed. As a
consequence, the value-adding services are not developed in a vacuum, but into the existing organisational
environment and reflected upon the actors with feedback to the developers. It is also rational to manage the
overall Architecture Landscape with appropriate visualisation tool, in which all the EA content (e.g.
organisation’s services, processes and applications) are coherently kept in an organised manner. The LEAF
provides the content metamodel and placeholders for the most typical elements of the EA content. This is where
the LEAD operating model plays a role.
4.2 The operating model
Traditionally, the EA adoption has required changes in current operating models, regarding IT/IS planning and
implementation, project and program management, and IT management (Seppänen et al. 2018). In contrast,
LEAD is based on the principle, that existing operating models and capabilities are utilised as much as possible.
The operating model may vary in the different cases, but the main principle is to guarantee the right capabilities
on demand in the Idea to Production value stream. This makes it easier to understand the development
processes. The LEAD Operating Model at high-level is presented in the Figure 6.
Figure 6: The LEAD Operating Model at high-level
Following the Idea to Production value stream (Figure 2 above and Figure 6 below), at the design phase a small
multidisciplinary demand management team takes care of handling all the incoming demands. The demand
management capability is the core capability of the LEAD operating model and the team co-operates in order to
find the most suitable solution for the customer’s demand. The team consists of specialists e.g. from customer
relationship management, operational development and enterprise architecture management and agile
methods and tools (e.g. Scrum and Kanban) are utilized in the process. The development phase contains build
or buy activities managed by the project management office (PMO), and detailed service- or business design
90
Eero Hosiaisluoma et al.
activities when necessary. The operations phase covers production capabilities managed by the service
management office (SMO). In addition, the Idea to production value stream supports portfolio management,
thus portfolios for ideas, development, IT services and applications are maintained within LEAF.
The aim is to keep the operating model light and to be able to change it when needed. For these purposes a
Lean Manager, is responsible for the management of the whole value chain, making sure continuous
improvements are made to the processes. In the LEAD, the architect’s role is to participate in the development
processes and give support when needed.
5. Findings form the case
The LEAD has been adopted at city of Vantaa. Vantaa is the fourth biggest city in Finland with over 220 000
inhabitants and located in the southern part of Finland. Responsible organisation for the LEAD was IT
department of the city. There were several reasons behind the decision to start planning and implementing new
way of reorganising information and communication technology (ICT) development, reasons like the lack of
overall insight and visibility of the overall enterprise development, and the siloed organisation culture in which
the EA did not have productive or cooperative role to support organisation’s ICT projects. Approach was too IT-
centric instead of being customer-centric, and overall organisation structure was containing also some
overlapping functions related to EA.
The main challenge was the poor effectiveness of the EA framework in use, which was an adapted version of the
Finnish national EA method. City of Vantaa had decided to use this EA method 2011 by the same time the Finnish
act was passed, making the use of EA mandatory. Unfortunately, the method was not considered to be suitable
for the organisation’s needs and caused a situation where stakeholders were not satisfied with the role of EA.
This resulted the management to question the usefulness of the EA practice.
By the end of 2016, the chief information officer (CIO) requested to completely redesign the IT development
process. It was decided, that the new development model should be more customer-centric, lean and agile; with
practical and cooperative architecture function in it. The essential target with the new development model was
to improve the demand management on the interface with internal customers’, and to produce fast and
justifiable solution proposals for these customers of the IT department. In the beginning, the new development
model was described as the Lean EA, aiming to implement lean and agile way to produce EA. For the effective
use of EA, tool support was needed and was operationalised. The tool (QPR Enterprise Architect) is used for the
EA visualisation and is provided free of charge by the Finnish government for public sector organisations’. It
includes the free use of the open publishing portal for the EA descriptions, that is provided by the Finnish
Population Register Centre as software as a service model.
In practice, the first version of the new development method was designed by the architecture team. The idea
was to establish a co-creation model in which most of the department’s specialists could participate. All the
phases were carefully designed by the team, and based on the plans following steps of the LEAD were
introduced:
The new role “Lean Manager” takes the leading position in the overall development, being the only new
role at the organisation.
New IT capability, multidisciplinary “Demand Management” virtual team is established for handling
incoming business requests. Internally the team is called “Solution office”.
The new lean and agile practices, methods and tools are introduced and adopted in the overall
development, such as web-enabled collaboration tools, backlogs, Kanbans, and daily scrums.
LEAD is deployed, Demand Management as its core capability, and architects are involved.
The EA team is reorganised. New chief architect is appointed outside the organisation and the new
governance model is activated.
The use of the EA visualisation tool is agreed with the CIO and taken into use immediately.
The LEAD Operating Model is introduced, and it defines organisational actors, processes and information.
The LEAF is introduced.
PMO and SMO are integrated into LEAD.
91
Eero Hosiaisluoma et al.
LEAD performance metrics are introduced and implemented.
Within one-year development period (Figure 7), the IT development work concerning all the main phases of the
LEAD method: Design, Development and Operations was reorganised. There are parts of the model that are not
fully functional yet, but LEAD’s lean and agile nature enables continuous improvements. For example, Demand
Management capability was changed, because it was considered too heavy. The number of participants was
reduced, design meeting was shortened and divided into general and technical parts.
To support open government principles and to provide knowledge for other public sector organisations, the
LEAD framework was partly published in the Finnish Population Register Centre’s EA modelling service. Since
the use of the Finnish national EA method has been challenging in many organisations, there has been a lot of
interest in the LEAD work in Vantaa and there are other cities starting the adoption of the LEAD.
Figure 7: The development process in Vantaa
The learnings from this first LEAD adoption can be used to help in the beginning of the work. It is very important
to have the support from the management from the start. In Vantaa the CIO’s strong support has abled the
acceptance of the new model and the change resistance has been moderate. Some functions were first not light,
fast and small enough in Vantaa and are to be redesigned. In the next implementation projects this should be
noted, to be able to keep the work as lean and agile as possible. There have been changes in the language used
about the development work, with the LEAD the key is to talk about adding the customer value and the need to
talk about EA itself is reduced. This is an advantage, since after the long and challenging implementation period
of the mandatory EA in the Finnish public sector, the word EA has become almost a swear word in the Finnish
public sector (Penttinen et al. 2018). When the EA is an integral part of all the development work, the
disconnectedness of the EA work is diminished.
6. Conclusions
The use of the national EA method has been mandated by law in Finland since 2011. In practice, the
implementation and use of the method have been challenging (Seppänen et al. 2018, Penttinen et al. 2018) as
the method is considered rigid, hard to understand, and its implementation and use requires a lot of resources.
There has been a need for an EA method that would allow easy implementation, be flexible and intertwined in
the existing development processes. Also, the customer viewpoint has been missing. In this study, we proposed
the LEAD as a solution to these practical problems in the use of EA in the public sector.
Using pragmatist-constructive approach, we studied the change as reflective practitioners. We first presented
the problem area by arguing that traditional EA methods have not been able to fill up the expectations of
92
Eero Hosiaisluoma et al.
business and IT alignment and using them is considered as a laborious and discouraging. Hence, we
acknowledged the need for revising EA. We developed a solution to the problems of traditional EA in the public
sector at the case study in the city of Vantaa. Here we present our solution, the LEAD concept. It combines Lean
management as value chain based operating model and agile practices into EA. The following four lessons are
learned. First, LEAD is a co-creation project with enterprise architects, developers, users and management. The
use of LEAD requires iterations and adaptation to the context of use. Second, we demonstrated the use of LEAD
by describing the findings from the case. From over a year lasting practical experience of using LEAD, we can
argue that the concept seems to be working. The key is to combine management, Value Delivery Chain and value
chain and Architecture Landscape to achieve targeted value to the customer by utilising agile development.
Third, the adoption of LEAD in Vantaa required substantial changes on service development and organisation of
the IT department. To succeed in making the changes and continues use, a strong top management interest and
support are required. Fourth, the LEAD in Vantaa was initiated as an IT department project, but further
development is aspired and needed to make it suitable for more extensive development settings, such as
accelerating digitalisation at the organisational level. Nevertheless, more experience, preferably from another
cases, is needed. To be able to evaluate thoroughly, more research is needed. The evaluation by comparing the
objectives of the LEAD to actual observed results from use of the artifact in the demonstration, is subject to
future research.
References
Banaeianjahromi, N. and Smolander, K. (2016) “Understanding obstacles in Enterprise Architecture Development”,
Proceedings of the ECIS.
Bloomberg, J. (2013) The agile architecture revolution: how cloud computing, rest-based SOA, and mobile computing are
changing enterprise IT. Wiley.
Bui, Q.N. and Levy, M. (2017) “Institutionalization of Contested Practices: A Case of Enterprise Architecture
Implementation in a US State Government”, Proceedings of the 50th HICSS.
Dang, D.D., Pekkola, S. (2017) “Problems of Enterprise Architecture Adoption in the Public Sector: Root Causes and Some
Solutions”, Information Technology Governance in Public Organizations, 177-198. Springer, Cham.
Drechsler A. (2015) “Designing to inform: Toward conceptualizing practitioner audiences for socio-technical artifacts in
design science research in the information systems discipline”, Informing Science: the International Journal of an
Emerging Transdiscipline, No. 18, pp 31-45.
Dybå, T. (2000) “Improvisation in small software organizations”, IEEE Software, Vol 17, No. 5, pp 82–87.
Dybå, T. and Dingsøyr, T. (2008) “Empirical studies of agile software development: A systematic review”, Information and
Software Technology.
FINLEX (2011) “Finnish Act on Information Management Governance in Public Administration”, in Finnish, [online],
http://www.finlex.fi/fi/laki/ajantasa/2011/20110634.
Gatti, R., Carbone, L., and Mezzapesa, V. (2017) “State of Play of Interoperability in Europe – Report 2016”, A study
prepared for the European Commission by KPMG, Luxembourg: Publications Office of the European Union.
Gill, A., Smith, S., Beydoun, G., Sugumaran, V. (2014) “Agile enterprise architecture: a case of a cloud technology-enabled
government enterprise transformation”, Proceeding of the 19th PACIS, pp 1-11.
Hanschke, S., Ernsting, J., Kuchen, H. (2015) “Integrating agile software development and enterprise architecture
management”, Proceedings of 48th HICSS, pp 4099-4108.
Hauder, M., Roth, S., Schulz, C. and Matthes F. (2013) “An Examination Of Organizational Factors Influencing Enterprise
Architecture Management Challenges”, Proceedings of the ECIS.
Hauder, M., Roth, S., Schulz, C. and Matthes, F. (2014) “Agile enterprise architecture management: an analysis on the
application of agile principles”, in International Symposium on BMSD.
Heiskanen, A. and Newman, M. (1997). "Bridging the Gap Between Information Systems Research and Practice: The
Reflective Practitioner as a Researcher", Proceedings of the ICIS.
Hicks, B.J. (2007). “Lean information management: Understanding and eliminating waste”, International journal of
information management, Vol 27, No. 4, pp 233-249.
Hjort-Madsen, K. (2006) “Enterprise Architecture Implementation and Management: A Case Study on Interoperability”, in
proceedings of the 39th HICSS.
Holweg, M. (2007) “The genealogy of lean production", Journal of Operations Management, Vol 25, No. 2, pp 420–437.
Hope, T., Chew, E. and Sharma, R. (2017) “The Failure of Success Factors: Lessons from Success and Failure Cases of
Enterprise Architecture Implementation”, proceedings of the ACM SIGMIS Conference on Computers and People
Research, pp 21-27.
Isomäki H. and Liimatainen K. (2008) “Challenges of Government Enterprise Architecture Work--Stakeholders' Views”,
Lecture Notes in Computer Science, 5184, pp 364-374.
Janowski T. (2015) “Digital government evolution: From transformation to contextualization”, Government Information
Quarterly, Vol 32, No. 3, pp 221–236.
Janssen M. (2012) “Sociopolitical Aspects of Interoperability and Enterprise Architecture in E-Government”, Social Science
Computer Review, Vol 30, No. 1, pp 24–36.
93
Eero Hosiaisluoma et al.
Janssen, M., Flak, L.S. and Sæbø, Ø. (2013) “Government Architecture: Concepts, Use and Impact”, in proceedings of the
12th IFIP WG 8.5 International Conference, pp. 135-147.
Kaisler S.H. and Armour F. (2017) “15 Years of Enterprise Architecting at HICSS: Revisiting the Critical Problems”,
proceedings of the 50th HICSS.
Lapalme, J., Gerber, A., Van der Merwe, A., Zachman, J., De Vries, M. and Hinkelmann, K. (2016) “Exploring the future of
enterprise architecture: A Zachman perspective”, Computers in Industry, No. 79, pp 103-113.
Lemmetti, J. and Pekkola, S. (2014) “Enterprise architecture in public ICT procurement in Finland”, in proceedings Electronic
Government and Electronic Participation: Joint Proceedings of Ongoing Research and Projects of IFIP WG 8, pp 227-
236.
Mumford E. and Weir M (1979) Computer Systems in Work Design: the ETHICS Method. New York, Wiley.
Nerur, S., Mahapatra, R., Mangalaraj, G. (2005) “Challenges of migrating to agile methodologies”, CACM, pp 72– 78.
OECD (2017) “Going digital”, In OECD Digital Economy Outlook 2017. OECD Publishing.
Ojo, A., Janowski, T. and Estevez E. (2012) “Improving Government Enterprise Architecture Practice -Maturity Factor
Analysis”, in the 45th HICSS, pp 4260-4269.
Open Group (2016) “The ArchiMate® Enterprise Architecture Modeling Language” [online],
http://www.opengroup.org/subjectareas/enterprise/archimate-overview, last accessed 2018/05/15.
Penttinen, K., Isomäki, H., Seppänen, V. and Tyrväinen, P. (2018) ”Revisiting and Revising the Grand Challenges of Public
Sector Enterprise Architecture”, Under review at the EJIS.
Rouhani, B. D., Shirazi, H., Nezhad, A. F., Kharazmi, S. (2008) “Presenting a framework for agile enterprise architecture”, in
IT 2008, pp 1-4.
Saha, P. (2009) Advances in government enterprise architecture. IGI Global.
Seppänen V., Penttinen K., and Pulkkinen M. (2018) “Key Issues in EA-implementation: Case study of two Finnish
government agencies”, The Electronic Journal of e-Government, vol 16.
Tan, C.W. and Pan S.L. (2003) “Managing e-transformation in the public sector: an e-government study of the Inland
Revenue Authority of Singapore (IRAS)”, EJIS, Vol 12, No. 4, pp 269-281.
TOGAF (2018) The TOGAF® Standard, Version 9.2 [online], http://www.opengroup.org/TOGAF-9.2-Overview.
Womack, J. P. and Roos, D. (1997) “Lean thinking—banish waste and create wealth in your corporation”, Journal of the
Operational Research Society, Vol 48, No. 11, pp 1148-1148.
Womack, J.P., Jones, D.T and Roos, D. (1990) The Machine That Changed the World.
94
