Hi, what I have seen at several customers is that there is not that one approach. "Libraries" is a quite flexible concept to put together things which belong to the same context, which can change of course, and then you re-group. I would not recommend to use it for asset types (like applications, processes), because for that you have already folders. Company / department -> yes, maybe. You could put together all processes, applications etc which belong to that company. Some companies do it that way. Others use it for programs, for as-is / to-be (especially if that requires extensive modeling work for process, application, capabilities etc). Thinking a little more about, we'll surely find more good use-cases for libraries, but I guess that gives you already some direction...
... View more
Hi as far as I can see BA is the core of your HX product configuration to describe business relationships (alternatively, it could be BPA). Maybe you'd like to consult this article in our online documentation: https://doc.mega.com/hopex-v2r1-en/#page/HBAS%2FBA_Mapping.Managing_a_business_architecture_environment.html%23ww1263501 The definition behind is: " A business architecture environment represents the relationships of a business functional area with its partners." ->> sounds like your channel.
... View more
Hi, business functions and business capabilities dont mean the same thing. A function is what you organization-wise have or should have in place, like marketing, sales etc, which then is "Instantiated" by one or many org-units. A business capability describes what your company must be able to do for current or future business. That's a more strategic element, and it has to be instantiated of course - sometimes by a process, sometimes by an org-unit, then you'll need maybe specific skills etc. A good example is M&A, if your strategy is to grow. M&A is not a single process, not only one org-unit will be involved etc. Does that make sense?
... View more
This is a very normal evolution: whenever a company is founded, it starts thinking about future clients and what they want, but then later, its focus changes from customer-centric to product-centric, and the main idea shifts from serving a market to making the product better and cheaper.
Take the example of opening the market for electrical power in Germany: that opening encouraged new providers on the market to offer price comparisons between the different electricity providers. In the latest versions of their web-based price comparison tools, you only have to enter 2 pieces of information: location and family size. Compared to the original versions, this is much more efficient and much more convenient for customers, including myself. However, consider what will be possible with the Internet of Things and connected devices like NEST? We can imagine that in the future, specific devices in the homes of families will be able to order electricity at the best price themselves without user interaction - and that will be even more convenient for end users. Ipv6, integrated sensors and cloud are the technical means and, just like Uber has disrupted the taxi business, once it is possible, someone will do it. Is comparing electricity prices a secured business model then?
Customer experience will be the differentiator for many companies.
Even though companies often have a good understanding of their current customers, they have difficulties anticipate customers’ future needs and behaviors. Companies rely less on the loyalty of their customers since competitive products are just one click away, and therefore companies have to find other ways to keep current customers and attract new ones. One possible route is to multiply the number of touchpoints with customers, while ensuring customer satisfaction is maximized on each of the touchpoints.
Now - what can you do?
Most IT roadmaps are currently based on typical business functions: sales, marketing and accounting. This results in the typical matrix views that have often been used in Enterprise Architecture for years: In Germany we use marketing application A, in France Application B. However, we need only one application, so we will try to consolidate. But this strategy leads to egalitarianism and thus primarily serves the efficiency paradigm, not the differentiation paradigm.
So you need a new IT framework: Primarily starting from the customer, and only after that, focus on business functions and other features, as explained in this article. By doing so, one can assess the IT landscape against customer journey requirements, and, per the example above, not just benchmarking your marketing application. That way you ensure differentiation rather than standardization. This is phase 1 (differentiation).
In Phase 2 (agility), you structure with a focus on business functions in order to define the performance framework for applications. Of course, you can’t be agile if you have too many applications in the portfolio: for example, 16 different time-recording systems. But that doesn’t mean you should only have one application that supports all business functions. It would be impossible to improve the marketing function of an application without impacting the sales function of the same application.
Business functions are therefore only the secondary breakdown characteristic. This serves the aim of agility: If the application is too large and supports many business functions, then a modification (new version, whatever), does not only impact one, but two or more business functions. Ideally, an application should not be so large as to impede changeability.
And finally, in Phase 3 (cost saving), the cost of production and time to market are relevant because this new and stronger form of customer orientation will be very costly itself. You have to save costs: All processes (and their supporting IT systems) that do not directly serve the customers are subject to this review. A great way to do so is to link customer touchpoints to those processes, which will result in an end-to-end customer journey. You will be able to understand exactly where you are in direct contact with your customer, and you will be able to understand steps and activities which do not provide value and can be streamlined.
OTT business models force established vendors into either a Bimodal IT or Multimodal IT. This does not only describe an IT landscape of 2 or more modes (e.g. safety and agility), but allows you to build an IT landscape structure with differentiating evaluation criteria. Processing speed can be one, but also technology, cost tolerance, functional fit to customer expectation, technical fit to mass production and more.
It is important that you are able to evaluate the different areas of your IT landscape against different evaluation criteria, each specific to one of the three phases.
... View more
Companies are forced to rethink their business models in shorter intervals, and adapt to new business models that will only be possible with significant support from IT. But necessary changes cannot always be planned with a long-term perspective. Customer behavior is difficult to predict. Due to this increased complexity, practical tools are necessary to create transparency and think through planning alternatives regarding your opportunities, risks and implications.
Under no circumstances should your horizons lead you to believe “What I do not see does not exist and does not need to be considered.” Lean, combined with enterprise architecture, provides a 360-degree view and is a sleek instrument for planning and managing necessary and inevitable changes.
The lean concept is as simple as it is ingenious: customer value-adding processes are prioritized and waste will, wherever possible, be avoided. "Adding value without waste" is the motto. On the basis of an open performance culture, based on trust, respect, tolerance, fairness, participation and integrity, and using lean principles and techniques, business processes are continuously and sustainably developed. This is especially true in IT management and enterprise architecture management.
Lean EAM is ultimately a cost-optimized way to rise to a challenge, but without renouncing the necessary panoramic view. Enterprise Architecture Management (EAM) is worthwhile if the sum of the personal benefits clearly exceeds the costs required for this. We call this target state "Lean EAM". Only a cost-optimized EAM application will be successful enough to fly.
Reaching this goal is not very easy. Five key factors for success are:
Lean principle of customer value orientation: Create individual benefits for the stakeholders regarding their daily work as it relates to helping them achieve their personal goals, e.g. accurately provide your enterprise architects with a view of the cost of the solution scenarios, delivering the information necessary for a decision. Conversely, everything that doesn’t add real business value is considered as “waste” and shouldn’t be delivered.
Benefit by use: At first this sounds banal - but it is not. Unfortunately, in many companies, you can often find people responsible for data collection activities who have no interest in the results of their own work. There are different reasons for this: It may be that in the past, specific data was collected for a specific project or initiative. Now that the project is completed, that specific data collection provides no value to the business. Or, sometimes there is a lack of focus on the essentials, which can lead to “data collection for the sake of data collection”. Only through legitimate and consistent use in their daily work, or to achieve a specific project objective, do users realize a personal benefit. We believe all data gathered under EAM should be able to be measured against three axes: strategy implementation, costs and risks. This is simple, but not too simple. It is especially important in the context of large initiatives that will significantly transform the company.
To create balance, focus on the essentials: Omit everything that is not effective and has an insufficient cost-benefit ratio. This refers to the substance structures, processes and organization. We know the cost-benefit analysis is certainly not easy. A thorough analysis is the key to success. There is no compromise.
Access to a high quality and up-to-date EA repository: The results of EAM will provide value in the long run, but only if the quality and legitimacy of the repository addresses the company’s needs. The data suppliers are generally specific people in the company, such as business analysts or solution architects. They are often under pressure to meet deadlines and therefore have neither the time nor the inclination to put in extra effort for no apparent benefit. Only through "recognized" benefits, making it as easy as possible, and the presence of "gentle pressure" from IT management and corporate governance, will the support of all required contributors and stakeholders be maintained. See the book, " EAM – einfach und effektiv," for best practices in this area.
Eradicate focus on problem-solving: Bottlenecks or errors, such as insufficient quality of data for the creation of an executive report, are to be fixed as a priority. Bottlenecks and failures significantly discourage the acceptance of EAM and the expected benefits cannot be realized. Those bottlenecks and errors can be resolved in different ways. On one hand, the data quality could be effectively enhanced with appropriate care and quality assurance processes. On the other hand, the decision template or the report could be amended to the extent that it is based only on high data quality. Here’s an example of HOPEX, where the validation can be easily performed by automated tools, and the data quality improved significantly.
Gradual, benefit-oriented expansion of EAM: The introduction and establishment of enterprise architecture management can only be done in small, manageable steps with visible, quick wins. Only if the benefits are recognized will there be strong arguments for investing in the expansion of Lean EAM initiatives. Continuous improvement must involve daily action and awareness (think of it as "Lean Thinking"). Thus, errors can be addressed, results are optimized, and benefits are increased.
How lean is your EAM? What would it take to get from where you are now to a lean state that could deliver more value? MEGA is hosting a webinar in German titled "Erfolgreiche Digitale Transformation mit Lean EAM und 360 Grad Perspektive". Come join us to learn more about creating a 360° view for your business through lean EAM.
This blogpost is co-written with Inge Hanschke - Inge is CEO of Lean42 and a well-known author of relevant publications about EAM, BPM, Business Analysis and Lean IT Management. She leverages her experience of 28 years of professional career as IT manager of several organizations in different industries.
... View more
The long-eared owl is quite different. It chases only at night, its diet is almost exclusively mice and small birds, and unlike the tawny owl, it hunts even in flight. Its tolerance range with respect to temperature and other parameters is considerably more limited than the tawny owl, which makes it unable to adjust to as many different habitats as the tawny owl. Its ecological niche is relatively small, and most importantly, it does not have the potential to extend this.
The long-eared owl is a specialist, the tawny owl is a generalist. At first sight, they look very similar and one could confuse them. The long-eared owl, however, has evolved to be extremely efficient. But in times of shrinking habitats and a rapidly changing environments, that is a weak strategy: it is currently very good at what it does, but soon the landscape and associated opportunities may no longer be there, and new opportunities may also be difficult to reach. The tawny owl, on the other hand, adapts to changes much better and is already in a larger ecological niche.
But why write about this for an IT blog?
Specialists and generalists are found in every environment, both in nature and at the office. There are also specialized tools and more universal ones. An example would be the difference between a scalpel and a Swiss army knife (in a figurative sense): a scalpel is very good but it has only one purpose, while a Swiss Army knife can do much more, but you cannot perform surgery with it. I would take a Swiss army knife on a long trip because I can use it in many different situations. Similar to changing ecological niches, I will certainly encounter unknown risks, and I must be able to adjust myself to different situations, be able to assess unexpected changes and weigh multiple strategies. Just like the tawny owl: I will be able to adapt much better.
Digital transformation is a journey with many parameters to be taken into account and with many risks in an unknown ecosystem of technological changes and customer expectations. As a business, we should be able to respond to external events as quickly and effectively as possible from the very beginning of the journey. This requires generalists rather than specialists: people and tools to accomplish goals, ways and means to identify and weigh alternatives as necessary, and the ability to consider costs and risks appropriately.
Our enterprise architecture (EA) solutions has been evaluated in a recent study from Syracom: Syracom Architecture Management Tool Survey 2015. It recognizes the value of enterprise architecture tools from the perspective of a generalist. This endorses the strategic positioning of the product, which aims to help businesses to best manage their digital transformation.
... View more
BCBS will also have a significant impact on the following fields:
Data Management: significantly higher data quality will be expected across all departments throughout the company, with a particular focus on the quality of risk data and consistency requirements. Although the responsibility lies at the board level, it will be necessary to establish a data governance framework and to document it.
Risk Reporting: In the future, reporting needs to be faster, more flexible and easier to understand for the user. Because of this, the level of automation should be significantly increased, and report generation has to be accelerated. In many organizations, however, reports are currently being "manually" created by using the “throw people on it” idea.
Business and IT Management: BCBS 239 must be reflected in the IT strategy and in the development of the IT landscape. How can this happen? Here, we need to understand how IT and data currently relate to each other, and how they will relate in the future. What happens during certain technological changes or changes in strategic direction? Will the company still be BCBS 239-compliant within acceptable levels?
How can an enterprise architecture approach help?
Enterprise architecture – because it is a design, planning and analytically-oriented function in the company - already offers the specific methods and approaches to create the necessary foundation for a lean implementation of BCBS 239.
Enterprise architecture provides a structured view of your IT architecture, data architecture and process landscape, while helping you to plan a risk-optimized target architecture. In a central repository (single source of truth) - as required by BCBS 239 – all relevant information and relationships are stored and documented. A central portal provides wiki-like information, but better structured, with well-defined model integrity mechanisms. Data models, data flow diagrams, process diagrams, architectural sketches with attached documents, automatically-generated risk reports and dashboards help you to better understand impacts, evaluate risks and compare scenarios easily, without much manual work.
An enterprise architecture should not only support the documentation, planning and analysis of data and IT architecture. At MEGA, we strongly believe that enterprise architecture should and can add value within the different departments of the company. This is why we offer our customers solutions that link enterprise architecture with risk management. Risk management supports companies in their process of risk identification, risk assessment and risk treatment while using the same process, IT and data model information.
As required by BCBS 239, risk-relevant information should be consistently captured and stored. The demand for faster, more automated and flexible risk reporting can be easily met by leveraging a central repository.
If you have not thought about it yet, you should definitely start as soon as possible. Globally relevant banks must implement BCBS 239 by 01.01.2016, while national banks have a little bit more time. As already mentioned, MaRisk will become obligatory for all banks in Germany.
Sources: http://www.pwc.de/de/finanzdienstleistungen/banken/bcbs-239-eine-herausforderung-nicht-nur-fuer-global-systemrelevante-banken.html https://bankinghub.de/banking/technology/regulatorisch-geforderte-datenqualitaet
... View more
At the same time, devices, machines, nearly everything which can be built, are becoming smarter, thanks to the unlimited addresses provided by IPv6, low cost connectivity and app development. And the cloud of course. What does this second trend mean for IT?
Well, we can already see some of this taking shape. IT is no longer only responsible for providing IT resources to support value creation like ERP, SCM, etc. It has evolved to become part of the product, and therefore gets a completely new role in organizations’ business models. In some advanced examples, products like cars, elevators, and windmills are permanently connected with their manufacturers, communicating information about operation, faults, usage, external circumstances and predictive maintenance. Some even go beyond and allow remote monitoring and control. Companies now have the possibility to invent new services and products, and combine them in new ways, better than ever before. Different devices (bigger and smaller) and cloud services can be integrated and… well… need to interoperate and communicate. While improving the operational efficiency of an organization’s resources is the main objective of what we can call classical enterprise architecture, the latter is a completely different approach. For a while now, this has been known as system of systems architecture, the underlying approach for most military-oriented architecture frameworks like NAF and DoDAF. The idea is to design autonomous systems instead of slicing an organization into layers from strategy to processes to IT. This means:
Systems are based on physical elements, smart components (software), and connectivity / communication capabilities
Systems are primarily designed to interact with other systems
Systems can be composed of subsystems, and subsystems can be reorganized into new systems
Subsystems can be elements of multiple systems, and since communication is standardized, the re-composition is quite flexible
A common example is SEAR (Sea Air Rescue). This system is composed of the following subsystems: helicopter, boat, satellite, and land-based control unit. The helicopter is composed of… and so forth. But it can also play a role in another system composition. All subsystems interact and communicate to deliver their specific, defined service.
Isn’t that very similar to the following idea: Cars interacting with the manufacturer interacting with mobile devices interacting with parking grounds interacting with traffic control interacting with car sharing in another city for user profile and so on?
MEGA has a long history with enterprise architecture and with system of systems architecture, and has combined both practices in its HOPEX software platform. This allows companies to follow both practices at the same time, enabling EA to help evolving processes and IT landscapes, and integrate IT with smart products to deliver new services to clients.
... View more
Who in medium to large sized companies are tackling the issue of Corporate Governance? Taking the approximately 90 participants of the conference as an industry subset, there were Heads of Audit, Heads of Compliance, and Heads of Legal in attendance. Most of the people in those functions have a legal background, are actually lawyers or have moved from legal department to compliance. Interesting to see was the number of attendees who were originally doing something else before the compliance hat was placed on their heads. As well, it was surprising to see how often the compliance position is a shared/part time position. Many of the participants wore more than just the compliance hat, or had teams that were made up of shared positions.
Do Governance, Risk and Compliance functions collaborate? Raising the topic of interdepartmental collaboration elicited responses across the spectrum. The general consensus seemed to be that most people know that the different functions should collaborate, but in practical terms, it mostly happens in the form of workshops and discussions like those at this event. Defined, programmed interactions supported by a common or shared tool seemed a bit foreign for most participants. The need for interfaces is there, but most had little to no idea what these could look like or how they would function. That Compliance and Audit are different is clear for everyone, but the differences and overlaps differ from one organization to the next. Further complicating the issues is the fact that borders between departments are often not defined, making it challenging to find the right interface.
What are the challenges for GRC departments? Most departments are overburdened with work and lacking necessary resources, while the demand for auditing, compliance checking and corporate governance in general keeps increasing. This can also be seen in the complex build of many of the departments, balancing full, part and shared staff.
How are the collaboration challenges being addressed? Most departments rely on MS Office tools such as Excel, interviews based on questionnaires, databases in which they store documented risks, Word documents for policies etc. The idea of a unique software system, respecting rights, profiles and separated data, but sharing the same model and structure is not easily understood yet. The value and benefits of such a tool is perceived, but the details of how it functions are unclear to a lot of practitioners.
What can be done to bring greater integration and alleviate current challenges in interdepartmental collaboration? Closing the current gap between workload and resources in compliance departments is where software can really make a difference. A Better integration of GRC departments requires bridging audit, compliance and risk on an enterprise structure level, the day-to-day activity level and the communication level. The enterprise structure level is important to ensure that processes, business units, and risk factor catalogues can be centrally coordinated, thus minimizing the likelihood of wasting precious resources on duplicated work. On the activity level it is important that action plan management is coordinated, findings documented and that process versioning and validation are done. The communication level is key to ensuring that work done on the other two levels is not simply written in a book and put on a shelf to gather dust. Communication can be done in many forms including a portal with different views for different people, aggregating dashboards, and report generation.
At MEGA we have been listening and have developed a Regulatory Compliance solution to provide answers to the resource gap challenge and help integrate the interfaces with the other GRC departments. A more detailed description of this solution can be found here.
... View more