Agility Through New Technologies

Posted on by
Reply

Without the capability of linking application development with the infrastructure such as servers, middleware and network your organization will most likely be in more trouble than the decision-makers think. Information technologies have a profound impact on the organization’s ability to reinvent its business model(s) and the products it produces and since organizations in various industries will experience new demands from their partners, customers and suppliers the role of managing the information technologies will become even more important. The new demands usually leads to demands for changes that applies for the organization’s portfolio of information technologies.

Over time the applications are integrated with middleware and new point-to-point integrations are designed among the applications in order to ensure so called quick fixes or through offensive or defensive development. Offensive and defensive development (Wagter et al 2005) adds to the overall complexity of the organization but as such it is not possible for the organization’s it-department to stop or reduce the complexity due to the dependencies to the environment.

Complexity cannot be reduced (Snowden), but if the decision-makers were properly informed they would be able to navigate among the levels of complexity and as such make the proper decisions when it comes to investments in the right it-projects and as such the technical architecture.

The Enterprise Architecture program has an advantage if it can produce artifacts that can link applications with hardware e.g. servers and show how the changes will impact the organization. This is capability can prove to be extremely important since it gives a better overview of the transformation process. The artifacts should be visualized in a way that makes it possible to show various stakeholders an easy introduction to what the artifacts mean and how the organization can cope with the issues at hand. The artifacts should be what can be named actionable there has to be some form of action plan that informs the various stakeholders (especially the decision-makers) on what to do next e.g. what can be done to avoid scenario C? And who is responsible? And when should the persons who are responsible act?

Scenario planning and simulation are two tools that are essential to facilitate the proper exercise.

Conclusions

Information technologies have become more important due to demands from the markets that demands better products (products that contributes more to the value contribution for the customers). Information technologies have a tendency to add complexity to the organization’s decision-making process and business processes which makes slows down the ability of the organization to adjust to the demands of the markets.

Enterprise Architecture is about harvesting, organizing, and exposing data that can be used for management information and informed decision-making. In order to achieve informed governance (the basis for informed decision-making) is the social relations and the ability to visualize the artifacts.

If the Enterprise Architecture program is able to visualize the important artifacts and ensure a form of scenario planning through linking application development with the IT-infrastructure the organization is able to navigate in the issues of complexity and as such enabling agility.

Agility through new technologies can only be achieved if the organization is able to deal with both application development and its IT-infrastructure and linking those two to one another.

The artifacts that are needed in order to simulate a scenario can be reused and refined in order to give the decision-makers a competitive edge that in turn will give the organization a competitive edge to adjust or reinvent its business models.

Sources

Snowden, D., The Origins of Cynefin (2007 – 2010).

Wagter, Roel, Martin van den Berg, Joost Luijpers, and Marlies van Steenbergen. Dynamic Enterprise Architecture: How to Make It Work. 1st ed. Wiley, 2005.

SOA for Profits

Posted on by
Reply

If you look for a great book on how to deal with the implementation and adaption of an Service-Oriented Architecture the book SOA for Profits is what you are looking for. The book was published back in 2007 but is still highly relevant. The focus is on handling the needed interaction with stakeholders to collaborate and define what have to be done and when it should be delivered in order to work around a burning platform for applications.

“The basic Concept is that all IT is composed of services” – Bieberstein et al (2007, p. 17).

Eventually the enterprise’s technical architecture will be compatible with an SOA typology and as such it might enable the enterprise to make use of the benefits, however, the benefits can only be achieved through the engagement of the various departments and decision-makers that makes use of the services that the IT department can provide them with.

“Above all, Service Oriented Architecture is not only a development within the domain of IT, it also has a far reaching impact on the organization makes use of it” – Bieberstein et al (2007, 17).

By saying this it seems like the approach to Service-Oriented Architecture will involve much more effort and many more resources and stakeholders than what is firstly expected. The various departments outside the domain of the IT department would have to be involved in the transformation. This means that the development of the transformation program includes the development will become much more complex and the effort of communication will become increasingly difficult.

Assuming that the Service-Oriented Architecture program is much more than the programming exercise and technology adaption exercise the importance of technology, the organizational aspects of the organization will become of a much higher priority. This means that new strategies would have to be dealt with as well.

“Indeed, the organizational aspect is of decisive importance” – Bieberstein et al (2007, p. 17)

It is in my opinion not a particular smart thing to assume distance the IT department from the other departments in an organization since it will only lay the foundation for the development of a stovepipe culture. Bieberstein et al (2007) doesn’t share this particular view and as such they make use of the notion of business and IT. In this case it can be unclear who the business is, however I presume it is safe to assume that the business is sales, operations, communication & marketing, call centers and a like. There are different levels also that would have to be taken into consideration e.g. those stakeholders who develops the strategy. The “business” would have to be engaged and Bieberstein et al puts emphasize this in the two quotes below.

“Another essential precondition in the implementation of Service Oriented Architecture is to start with the business” – Bieberstein et al (2007, p. 19).

“Indeed, the organizational aspect is of decisive importance” – Bieberstein et al (2007, p. 17)

Clearly the implementation of an Service – Oriented Architecture is not without consequence and as such the primary problem is the recalibration of the social structure of the enterprise. Likewise is the sharing of a vision for SOA probably very difficult since not every individual in the “business” will invest time in understanding why they would have to define services or why they should collaborate with the IT department on anything. It will prove much more difficult if the IT department hasn’t been able to get the basics right in the past. In other words the Chief Executive Officer, The chief architect and the various other managerial positions within the organization would have to go on the upfront with communication and networking in order to ensure progress.

You can’t escape SOA

The authors present the concept of the SOA typology as inescapable.  The big vendors of enterprise-oriented software have already implemented the capabilities of SOA – protocols that enables the application to work with an enterprise service bus (ESB). As a result most enterprises will overtime experience that their applications will be made compatible with the SOA typology out of the box and as such it could be a waste of resources that the organization doesn’t make use of its technical capabilities. As such Bieberstein et al argues that it will become more likely that organizations will implement SOA like systems and eventually adapt the form of architecture. This the authors express in the quotation below.

“SOA is inevitable in the long run. An increasing number of major suppliers and end-user organizations are applying SOA. This means that more and more software and hardware is being based on SOA, that an increasing amount of functionalities are being made available as services, and that a growing number of chains and co-operative endeavors are being structured in a service-based manner. This, sooner or later, there will be no escape.” – Bieberstein et al (2007, p. 37)

You can’t escape SOA because the ecosystem (suppliers and to some degree customers) expect your organization to make use of services.  With this in mind Bieberstein et al (2007, p. 55) states that the two most important functions to be deal with in implementation of SOA is enterprise governance and enterprise architecture.

The organization has to emphasize the implementation of SOA on the foundations of the progress of the enterprise architecture program. In their effort to implement SOA the stakeholders would have to collaborate extensively on defining, scoping and implementing SOA in the context of how the organization works. Enterprise architecture is to some extent the framework for the governance of the SOA Without governance the effort of implementing SOA will not succeed. The purpose of governance is partly to navigate the complexities of the ever-evolving IT-landscape (Bieberstein et al, 2007, p. 58).

Consequences by implementing SOA

The organization would have to deal with the consequences of implementation of SOA. A SOA project (and later on a program) is resource demanding, since it would have to allocate the time of enterprise architects, SOA specialists, business architects and business partners. Likewise will the SOA project allocate time from various stakeholders outside the IT department since they would have to be educated on defining business services that would be used to model the technical services upon.

The allocation of resources means that the organization would have less access to deal with projects that might be within the sphere of development with architecture. The major issue is the concept of opportunity costs and as such it would become a necessity to deal with the problems that arise from not being able to allocate all available resources. Bieberstein et al mentions the consequences on page 34 to 35 where they mention the consequence of the adjustment to business processes, governance of architectural process changes, IT development related to the processes and administration of process changes. Likewise will the SOA approach lead to a need for retraining of IT personnel and training of the stakeholders outside the IT department. In this context it become much more interesting to convince those decision-makers who are in charge of the budgeting to allocate resources to fund the training activities along side the need for new tools to govern the services.

Business Vision

In order to deal with the implementation of an SOA based typology it would have to be dealt with the articulation of a business vision. Bieberstein et al (2007, p. 23) named it the SOA business vision and it consists of five stages as listed below:

1. Reason has to come from both within and outside the organization (p. 31) and the legacy systems in the organization’s IT – landscape can prove to be a great platform for engaging in change. Bieberstein et al sees this as “.

2. Benefits have to be identified and the benefits would have to be articulated as specifically as possible (p. 31). Bieberstein et al sees this as the “why” question.

3. Definition is the “what” question and is according to the authors just as important as the “why” question to answer in order to articulate the SOA business vision

4. Consequences by implementing SOA are many e.g. training of the individuals within the enterprise, opportunity costs, acquisition of new tools

5. Implementation is the last of the five phases and includes the implementation of wrappers, protocols, ESB, business services, XML protocols and standards and the implementation of the organizational structures.

The core to implement a SOA typology in an organization is to have defined the proper SOA business vision and engaging the right stakeholders. Governance is a must and Bieberstein et al indicates that the framework Dynamic Architecture.

Dynamic Architecture

The approach to Dynamic Enterprise Architecture  (Abbreviated Dynamic Architecture) is a framework that focuses on the process of architecting. The scope of Dynamic Architecture is to focus on issues that aren’t a part of a speedy defensive strategy that demands the resources of the IT department to deliver it-based solutions and likewise it isn’t based upon an offensive strategy that demands development of applications or services needed to gain market share.

Conclusions

All in all, the book “SOA for Profits” is a great book dealing with the organizational challenges for implementing SOA. Many ideas presented in the book are necessary in order to gain the true potential of an SOA since it would take the development of systems and integration to the various organizational aspects of development e.g. the transformation of stovepipe orientation to a holistic process orientation. SOA is inescapable and eventually most organizations would have to adapt applications that have been optimized for a typology based on SOA.

The primary challenge to gain profit (or harvest advantages) by applying SOA is through the maturation of the organization and through the departments that collaborate on dealing with the data and functions needed in order to make the technical and business processes deliver the full potential.

Sources

Bieberstein, Norbert. Berg, Martin and Ommeren, E., SOA for Profits, 2007.

Philosophy of Enterprise Architecture

Posted on by
1

I attended the summer school dealing with enterprise architecture that took place at IT University of Copenhagen in week 31 of 2012. A lot of interesting presentations and debates took place. I found quite a few interesting topics to think about and one of them dealt with the philosophy of enterprise architecture, which is the main theme of this blog post.

There are many interesting view points on enterprise architecture, what it should be used for and how to create value with it. In practice there are quite a few enterprise architecture methodologies that are used very differently from organization to organization.

Observations of Enterprise Architecture

Most of my observations indicate that enterprise architecture is build upon identifying, organizing and exposing management information that deals with applications (software), technology, and processes in order to deal with them.

The idea is to navigate in complexity of the information technology that the organization posses. In certain cases the chief architects have been able to produce management information that has had an impact on the decision-makers in order to define what kind of information technology and to a certain extent how to deal with (e.g. prioritize) what particular it-based projects that should be dealt with through allocating resources to them.

A Quest for Defining the Philosophy for Enterprise Architecture

Mika Helenius (Aalto University) has done some research on the basics of a philosophy for the concept of enterprise architecture. He presented some of his findings and facilitated a debate among the practitioners, students and academics.

His findings suggested that enterprise architecture as such suffers from the blessings of multi-disciplinary approaches where social science, natural sciences and the science of architecture which seems to be a form of art and a form of aesthetics.

These different forms of sciences, methodologies and ways to approach problems usually result in some form of clutter and it can result into increasing complexity when defining and dealing with enterprise architecture from a science point of view.

Observations of Scientific Paradigms Related to Enterprise Architecture

There might be confusion of the ontology and epistemology and it might add extra complexity to the concept of Enterprise Architecture, or at least it appears to be so. However from my point of view the concept of enterprise architecture can be closely linked to cybernetics and for that matter systems thinking. In my opinion isn’t it out of scope to apply elements from the paradigm of social-constructivism since quite a large part of the concept of enterprise architecture would have to be related to social sciences and in practice quite a lot of effort would have to be invested in the social aspects of communication, changing the behaviour of various stakeholders of the enterprise and ensuring that the change is anchored in the organization. A socio-technical or social-constructivist approach would to some extent be able to explain the construction of the Enterprise Architecture program and decision-making.

If the paradigm of systems thinking is applied in order to achieve an understanding of the concept of Enterprise Architecture, the primary definition of the concept of Enterprise Architecture would be that the purpose of the system is what it does. This means that the concept of Enterprise Architecture would be defined differently from organization to organization. I never really experienced that the EAP has delivered the same kind of artefacts or applied the exact same kind of approach in order to identify, organize and expose the artefacts. If the concept of Enterprise Architecture cannot be defined besides on an individual level it would seem nearly impossible to define a proper philosophy for Enterprise Architecture program.

Conclusions

There is still a lot that can be done in order to understand the concept of enterprise architecture. To a certain degree I believe that the best approach in order to define the concept would be through by applying the cybernetics paradigm or a social-constructivist paradigm. The reason for why these to paradigms are interesting in an Enterprise Architecture context depends the perspective that is put on top of the concept of the Enterprise Architecture they would be able to deal with the explanation of the social systems which seems to be the dominant part of the practical approach to Enterprise Architecture and explaining the nature of systems where humans interact.

The cybernetics paradigm can explain systems of humans, technologies and structures. From a purely organizational point of view the branch of cybernetics known as Management Cybernetics be applied and the main focus is to define system and its feedback and control mechanisms.

The social-constructivist paradigm can be applied in order to explain how groups of humans construct their own realities and own code of conduct to produce information and deal with problems that occurs within the system.

Summer School (Week 31, 2012)

Posted on by
Reply

I have been fortunate to participate in the Enterprise Architecture summer school that took place in week 31 in year 2012 at the IT University of Copenhagen. There where a lot of interesting presenters, academics and practitioners. One of the more notable presenters where Martin van den Berg who happens to be one of the authors to the book “Dynamic Architecture: How to make it work” and “Establishing an enterprise architecture practice”.

Furthermore came a lot of presenters from Finland who had researched the concept of Enterprise Architecture and a chief architect from a major Finnish/German Corporation.

This particular blog post was written in order to give you some insight in what happened with one of the presentations and I plan to release more blog posts dealing with the thoughts I have had during and after the summer school.

Innovation for Enterprise Architecture

The presenter, Mr. Kim Peiter Joergensen, argued that the enterprise architecture program has had little impact on the business. One of the reasons for this was the way that the enterprise architects usually developed their business artifacts. That triggered reactions from most of the practitioners who attended the summer school and as a consequence the keynote turned from being a presentation to a debate.

I was not particular impressed by the rather true, but rather stereotypical ideas of how enterprise architecture has impacted the organizations ability to invent and produce new products. From my perspective it really depends on how the organization and the chief architect approaches the concept of innovation and for that matter the concept of inventing.  Mr. Kim Peiter Joergensen should have worked with his preliminary (definitions and principles) for what invention and innovation is in an enterprise architecture context and that could have improved his presentation quite dramatically.

I believe that innovation is about identifying inventions (e.g. software, concepts, methodologies etc.) and identifying their fitness for adaption in the enterprise and its business, application and technological architecture. One example of this could be an enterprise architecture function that handles and develops the technology strategy.

In despite of the rather alternative way of defining enterprise architecture and invention or innovation, Mr. Kim Peiter Joergensen’s presentation did develop some ideas of how to approach this particular issue. First of all an exploration of the topic would have to be dealt with through defining the perspectives and how innovation and the concept of inventing.

Observations

The Enterprise Architecture function can enable the time to implementation (and essentially market) by developing and maintaining a technology strategy where the architects identifies new technologies and concepts that can be implemented in the organization.

The Enterprise Architecture function can enable standardization that makes it possible for the various applications to communicate with one another and as a consequence ensure a faster implementation rate of processes, software and concepts.

The Enterprise Architecture function can identify needs for reengineering of the structure of the organization’s structure.

Management Information for Managing Innovation

Posted on by
Reply

Management information is not particular difficult to produce, it is difficult to make use of. Management information can be produced in quite a few ways and supported by quite a few methods, but too much management information will eventually clutter the line of sight of the decision makers and as such work against holistic management. This blog post will outline some ideas; I have for particular artifacts that can enable the Enterprise Architecture function to deliver the necessary management information to decision-makers in e.g. IT Governance boards.

Enterprise Architecture is a philosophy, a methodology and a way to produce management information, and to some extent Enterprise Architecture has proved to focus too much on documenting the so-called as-is situation. In my opinion, the Enterprise Architecture should focus on identifying potential innovations that could be implemented in the organization’s enterprise architecture and create value for the stakeholders. However in order to delimit the scope of this blog post I would prefer to apply a definition by Anupinidi and Coady (2012) that essentially states that Enterprise Architecture is about guiding the information technology to the desired strategic position for the organization.

 

The stakeholders usually have different values and different ideas of how innovations like applications, devices and hardware can create value. In such case it becomes a necessity for the Enterprise Architecture program to deliver forecasts for what kind of technologies and concepts that could be of interest for the organization and provide road maps that can enable the implementation of them.

Models

There are several different approaches to estimate what particular innovations (in this case technologies and concepts) would be available and when to invest in them. The Gartner “hype cycle”. The model is far from perfect and to some extent the model can only be used as an inspiration since the model doesn’t ensures feedback of any kind. Gartner Incorporated applies pretty much the same model each year and they put a lot of models on the same though with some differences in chronology (how long time has the concept been on the hype cycle) and the concepts that are mapped on the hype cycle are “strangely” also a part of the service portfolio that Gartner incorporated sells to their customers.

 

The Enterprise Architect would have to use caution using the “hype cycle” since to some extent the hype cycle could give potential stakeholders a wrong impression of how mature the various innovations are. However the hype cycle can be used in order to categorize information and the model can be enhanced if the proper feedback loops are added to the model and its slopes. In order to provide guidance to the stakeholders and thereby providence to the decision-makers, the Enterprise Architect should define artifacts that are relations to the hype cycle.

Artifacts

They way I see it there would be three types of artifacts that would support enable the kind of management information that I would like to see the Enterprise Architecture deliver. The three artifacts can in combination give the decision-makers in the IT Governance boards a sense of what kind of information technologies and concepts that they should invest in:

1) Roadmaps for technologies are key in order show the stakeholders where the technical architecture is expected to develop.

2) A roadmap for the development of the products that the organization produces.

3) Roadmaps for processes are key in order to produce the products and services that the customers or clients of the organization.

A meta-layer to the three roadmaps would have to be added e.g. how do the processes enables the production of the products and furthermore how the technology enables the people how interact with the processes to develop the technology. The meta-roadmap should give the stakeholders an impression of how the innovations could ensure capabilities that the organization could gain competitive benefits from, if the proper investments are made.

Beyond the meta-roadmap

It is possible to combine the meta-roadmap with capability maps and scenarios. Capability maps have a slightly different focus and scenarios are usually applied for several different factors for the organization if a desired change of strategy is needed. The meta-roadmap can supply information (artifacts) to the strategically oriented models.

Conclusion

There are several different approaches to management information and how the Enterprise Architecture program can enable the production of the right amount of it at the right time; however there are certain approaches that might turn out to be more interesting than others. Innovation is to some extent the opposite of enterprise-archeology and as such it seems right if the Enterprise Architecture function provides makes use of a model like the hype cycle (preferable a slight modified edition) in order to structure the outlook for innovations (like technologies or concepts) that the organization might benefit from if it invests its resources properly. In order to go beyond the hype cycle, then roadmaps would have to be developed and make use of the data from the hype cycle.  Such roadmaps should lay the foundation for a meta-roadmap that shows how the various technologies or concepts would enable the enterprise to deliver current and future products when or if the proper investments are made and the implementation of the technologies have been sequenced the right way. Furthermore the meta-roadmap can and should provide information to strategic scenarios and capability maps. In order to give you a more detailed insight into the artifacts that I have briefly mentioned in this blog post would have to be explored further.

Sources

  • Ph.D, Nagesh V. Anupindi, and Gerard A. Coady. Enterprise Architecture Turnaround. Trafford Publishing, 2011.

The Technology Strategy

Posted on by
Reply

Many organizations are to some extent dependent on using information technology to deliver products or services to its customers. This applies to organizations within the private as well within the public sector.

There is some form of hierarchy among strategies that relates to the enterprise information technology strategy (IT strategy) and there might be some need to divide the strategies in order to specialize them e.g. through different persons who have the responsibility for the strategies or ensuring that the relevant information is screened to the relevant stakeholders. I hereby assume that the chief executive officer wouldn’t be that interested in particular technological products e.g. which edition of JAVA should the company’s IT-department be using or which particular server platform would be preferable in order to keep track of smartphones and tablets?

The technology strategy deals with the “hard side” of the technology. Which products, programming languages, databases, hardware, operating systems, back end platforms, ERP systems should the organization make use of.

What is the Technology Strategy?

The technology strategy deals with articulation of plans, roadmaps and principles for which information technologies that the enterprise should make use of.

The technology strategy is all about giving the decision makers some guidance on how to ensure to get rid of systems that only adds risks to how the organization does its business.

Systems that potentially will not add any kind of value to the business and instead seems like a liability own and be a part of the application portfolio.

Relations to IT-strategy

The technology strategy is delimited to deal with information technology (abbreviated IT) and as such the technology strategy can be related to the usage of IT strategy.

The difference between the technology strategy and the IT strategy; is that the IT strategy usually makes use of a long term description of goals that ensures that the IT department will enable the “business” with achieving its goals and adding bits to the a platform that could be turned into competitive advantage if used correctly.

Who formulates the Technology Strategy?

In many medium and large sized organizations have usually two types of technically related chief executives. The first one is the Chief Information Officer. The second one is the Chief Technology Officer (abbreviated CTO) who is more focused on the application portfolio, platforms and hardware.

The two of them are responsible for different perspectives of the enterprise’s usage of information technology; however it is more likely that the CTO reports to the CIO than the other way around.

The two would have to collaborate on delivering plans that can improve the organization and its usage of information technology.

How do You Formulate a Technology Strategy?

There are many ways to formulate a technology strategy and the way I see it the most important thing is to deliver results through changes investments behavior.  In this regard I assume that a technology strategy would have to be dealt with through the articulation of principles.

Greefhorst & Proper (2011) have written a rather interesting book named “Architecture Principles” and as such their approach to formulating principles can be made use of in order to formulate proper principles that can be incorporated in the technology strategy.

Conclusions

A technology strategy is usually used for ensuring the organization’s ability to gain a return of value of the investments it has committed to the applications, systems, platforms and development can be gained and turned into an advantage.

In order to do so the CTO has to collaborate with other profiles like the CIO in order to develop coherent strategies for the organization’s it-architecture. In order to make a sustainable and resilient strategy it has to be build upon principles.

The next blog post that I plan to publish will deal with principles and how a good principle is formulated.

Architecture Capabilities through Business Models

Posted on by
Reply

For some time I have been working with adapting the business model canvas for explaining how an enterprise architecture program delivers value to the it-department. The scope of the model has been on the foundation architecture where the outcome of the enterprise architecture program is mainly used by the IT department.

I am aware of that Tom Graves has done something similar, though he has made a completely different model, and as such his model is fine, but the audience that I intend to communicate with would be more likely that they will understand the value proposition of enterprise architecture through a model designed upon the business model canvas compared to a model based upon Graves’ model.

As you might have guessed then I had to adjust the business model canvas in order to expose the data on how the enterprise architecture program delivers value in the best way possible.

The first seven phases have been renamed in order to adapt the model for how a department or function within an IT department delivers values.

The first phase is about key partners needed in order to produce any form of value by the enterprise architecture program.

The second phase is about how the key activities that are needed in order to produce value. The needed activities would have to be organized around on handling the resources.

The third phase is about the key resources needed to produce the services or products needed by the segments of the it department.

The fourth phase is about the value proposition. In other words its about the initiatives at hand.

The fifth phase is about team relations and they are usually essential for both implementing and producing the services. Especially if we assume that enterprise architecture is about creating value through others.

The sixth phase is about channels. How does the enterprise architecture program deliver resources

The seventh phase is about the segments of the IT department that receives the services from the Enterprise Architecture program.

The eight phase is about the Enterprise IT Investment structure. This particular section of the business model deals with the identification of how the current situation of the IT Architecture the IT organization processes.

The ninth phase is about scenario planning, that deals with planning for a better IT Investments for the IT department.

The tenth phase is about the Improved Enterprise IT Investment Structure that deals with multiple actionable plans for changing and optimizing the total architecture.

All together these phases can present the necessary data to the decision-makers in order to give them an insight on how enterprise architecture delivers value to them. Value is key in situations where organization have limited access to resources.

The Architecture Business Model

The Architecture Business Model.


The foundation architecture is as earlier mentioned scoped on delivering value to the IT department and through to the IT department to the rest of the enterprise. The model is published under the Creative Commons license (share alike).