Now we are getting multiple hits all at one. We have gotten the AI creeping into the business and digital barons spawning with it. Realignment of politics everywhere. Massive transfer of economy from the middle class into the upper echelon of the billionaires. Climate shifting and dragging with it people. Lower birthrate worldwide. The infringement of governments over their citizens. And now we are getting news that UFOs are real!

As the old saying in Chinese culture: may you live in interesting times. We are indeed living it.

The next ten years will be studied for generations in the future, that is if we can handle our way though it.

Ya and about that Chinese saying, it is fabricated by none-Chinese in the USene

The thing starts by showing the old diagrams to see which one they want, then negotiating which one will fit and then changing it to the one gives the vibes the seeker looks for. There is no “one diagram” that shows everything, there will never be “one architecture” for all. It is about what details one wants to see, the viewpoint. Let’s not indulge on what defines the logical architecture and the physical one.

Maybe the diagram is what sticks together the role of the architect. Everyone wants to see his squares and how his square is related to other squares. It is becoming a square-mania with colors and annotations.

Going back to the request. If you don’t follow with your stakeholder, you will eventually have something wrong to present. It will either be more detailed or not the thing they want. So, unless you show it in stages then it will eventually be rejected to spend extra hours after your work rushing and have something ready. And by the end of the day, you will have the squares to be used once and never to be mentioned again.

The post The Squares appeared first on Discovering Change.

Everyone is rushing to the digitizing everything they can get their hands on without even understanding where they are at! It is all a game of having initiatives to show it to the top dog to receive points and applause. Let’s digitize it and ask the marketing team to have a campaign with all the smiles and happiness all over the country. 

I had the unfortunate event of having to visit a local company, NWC, to ask them for a service. Well right at the doorsteps the security guard stopped me and ask about my business. Well, sir, I am here for service X. To which he responds go and order that through our mobile app. OK…. so as long as I am here why not see a representative. The answer, un-shockingly, is we don’t have any more representatives it is all digital from now. And as I turn, an old guy was asking about the same services, the security replied with the same. The old guy said he doesn’t even have a smartphone to which the security said it is none of his business.

The misunderstanding of customer needs and disconnecting the essence of the company from the real world, along with the good old monopoly, is what results in this abuse. And with that cutting all corners in the name of Digital like they are not introducing bugs in the system but features!

The post Intentionally Left Behind… appeared first on Discovering Change.

Before discussing what is going on at the moment, let us go back to 2007 when the public sector started to catch on the “things are changing” reality. It wasn’t local here; the rest of the world was experiencing the early days of digital disruption. At that year, the government incepted Yesser’s program to establish the E-Government backbone. At that time, every consulting & researching firm celebrated the new era of interconnecting systems through the SOA approach. That experience resulted in a seamless customer experience for a small set of government services. It wasn’t about the technical challenges but related to understanding the core principles of SOA and breaking the business services before the technical capabilities.

Nevertheless, people saw an increase in the quality of government services with fewer visits to regional offices. This continued with new integration approaches outside Yesser’s GSB & GSN. Elm & Thiqah pioneered in the public-private partnerships and generating new revenue streams for the public sector. Well, it was mostly managed business operations with zero overhead on the public.

All the sectors remained on this path until the 2020 & 2030 vision plans, where Saudi had an explosion in modernizing all the public sector infrastructure and especially on the information technology field. And from there, the consultancy firms didn’t hesitate to take their share by bringing new visions and frameworks to make the public spending justifiable. The firms incepted the idea of the Digital Transformation as the new frontier to discover.

Throughout my experience with multiple Digital Transformation initiatives, I have noticed that consultancy firms anchor their deliverables on four pillars:

• Cloud technologies

• Data technologies

• Customer Journies

• Modernizing any IT assets in need

And from there, you get the project cards, budgetary estimates, and the KPIs. From time to time, you will see throwing emerging while suggesting that those emerging should take the backseat to the more critical pillars. There are no questions about the “why” part of the architecture, only the “what” and “how.” The premise of becoming digital is absent from the scene; give us the consultancy work and move from there. We have a due date to catch!

No wonder that 70% of the enterprises fail when delivering Digital Transformation projects. Organizations don’t understand the premise of becoming digital. And the public sector more susceptible to this due to the unclear Value it provides to the market (I tend to exclude the Proposition part of the Value Proposition from the public due to their regulator nature). And what the consultancy brings is only what the client wants and, in most cases, power and reasons for budgets. The consultants stay for three months at max to present a couple of presentations capturing a typical business systems planning with the everchanging technology landscape.

Digital is a change in culture, behavior, and heart. You can’t claim to be digital by buying COTS without a differentiating your business model to exploit the digital benefits. And I don’t mean by developing the business model canvas and stopping there, but rather rebuilding your model by cutting much of the waste and bringing business innovation. In this day and age, it isn’t enough to expose your services through a mobile app or a website. Going Digital requires a complete reversal of how the organization looks into itself from within and navigating the views from its boundaries.

The post The Digital Transformation Paradigm in Saudi appeared first on Discovering Change.

So before starting the practice, I suggested driving a Metamodel or the elements defining my system. And for that, I went to Archimate to pick some elements along with a weak relationship type. As for choosing this Architecture Description Language, I have expressed multiple times my fondness in Archimate, and I genuinely believe it is an excellent modeling language by the Open Group. Nevertheless, Archimate evolved at a rapid pace, and right now has more than fourteen elements that are overkill for most scenarios, even for huge enterprises. But the good thing about Archimate is that its metamodel allows for any extensions and derivations to suit the architect’s need, which fits my situation.

I didn’t want to overkill the metamodel, so I picked only five elements:

As for the semantics, I tried to make them simple and straightforward:

• Capability: Presents high-level capability the client’s needs to acquire, like Managing Applicants.

• Business Object: An information mapping from a business perspective. Mostly, this defines a concept within a business, e.g., insurance paper, correspondence, car.

• Application Component: The application component that was developed or acquired, e.g., Site Postal. Any component that is displayed and functional to the end user fall within this group( e.g., User Management).

• System Software: A technology that serves the custom application component like the OS, Database, or application container.

• Artifacts: Any binary that supports the development of products, e.g., Libraries, frameworks, media.

As for the relationships, I just picked the association as it represents the weakest type of within Archimate. Plus, it abstracts a much more complicated relationship through the derivation feature in Archimate. The reason for one type of relationship is to prevent complicating the models & viewpoints; plus, from my experience, architects tend to fall into analysis paralysis state when it comes to modeling.

This metamodel should be enough to bootstrap the process and should present the necessary architecture without overcomplicating the products’ architecture.

As for the modeling tool, I suggest starting small with no financial burden to carry. One particular tool I suggest to people is Archi, which is a wonderful one for Archimate modeling. And it is free!

The post A Simple Metamodel for Architecting Products appeared first on Discovering Change.

I tend to describe such change as the holy trinity. And what I mean by that is when the motivation is already set up for a change from stakeholders, whether a shareholder, a regulator or internal intend, then it becomes an input for a grand level of organization change. I can describe the holy trinity by the following diagram.

This most simple change you usually witness is when an intention or motivation is communicated to the strategy office in which it directly transforms the strategy into initiatives and KPIs. Once the projects are defined, it is taken to the domain architects, or SMEs, from each department to carry out the solution change, whether through internal or external support with the Project Office support. This approach, although successful, finds itself in front of a change paradox that minimizes the impact across the enterprise. So assume that a current change requires an enhancement in a value stream and value proposition that is already critical to the enterprise, so how much change should happen?

Luckily; most of the value streams for small and medium enterprises are straight-forward and rely on one information system. So, it is a matter of a complete solution delivery while maintaining the aspects of the old one like the processes, migrations, and parallel runs. But what happens if a change is one that applies for a sophisticated and convoluted value stream, or rather a change that changes the dimension of the business itself, then how could direct projects cover such complexity?

The is more advent in large enterprises where a change might become such a complex that might take years to deliver. Moreover, change usually happens at a capability level and not at the value stream due to the convolution o the change (thank God for the advancement in API and SOA!).

Luckily, a trend has been progressing within a couple of last years, and that is to embed enterprise architecture as a critical element in planning and orchestrating transitions. In this approach, although not one dimensional, the enterprise architect, along with domain architects, will analyze the need for change from business architecture lenses. Here, value streams, information, organization hierarchy, and capability will be analyzed for the need to change. And then, after examining the need for change, an impact and benefit models will be developed along with multiple optional solutions, much like scenario planning. In the end, a resolution is adopted with collaboration of the EA office, domain architects, and portfolio management office.

This is not strictly followed, however, but it provides the best baseline to have a business-outcome enterprise architect with a more significant benefit across the enterprise as a whole. Nevertheless, in the board universe of EA, there is no approach without its critics, which is fine as long as the one understands what he/she is into. 

The post The Holy Trinity for Enterprise Change appeared first on Discovering Change.

The workshop started as a 3 hours activity where the participants, within and outside the organization, sat at tables. Then a consultant began to give a brief on the client situation and to the purpose of the workshop. By then, a group of consultants started to guiding people on defining problems, segmenting them, and innovating solutions. In the end, the consultancy firm organized and prioritized multiple solutions and concluded the workshop by thanking everyone and giving certificates & souvenirs for the workshop. After the workshop, nothing happened other than presenting the findings as PowerPoint slides to the client with no further action points. The rest is history, and the client has with him a document that is worth its weight in gold!

What happened is a typical scenario that you will find happening time and time, with different names and different faces. The design thinking practice was brutally misinterpreted and abused to a level where its actual benefit was lost even before activating the methodology. The whole purpose of having to say like Design 

Thinking is to allow organizations, teams, and individuals to navigate the complex maze of uncertainty to identify the problem and throw quick solutions to test if the hypothesis and fail it as early as possible. It is nothing but a non-holistic approach to analyze complex systems. And for those old geezers, you might remember the prototyping software approach, the 90s if I recall correctly, and how it eventually got absolved to resurface again as an outcome of the scrum and advancement of technology for rapid development & deployment (DevOps).

I recall listening to a Gartner’s podcast where the host was talking with a guest who did a large project in India through the following Design Thinking approach to solve a problem facing Indian farmers. The farmers would gather their crops and go to the market, and the market was controlled by a monopoly of merchants who buy the produce at night and then substantially increase the cost on the end consumers. The guest was describing their approach in empowering the farmers to get their fair share from the transactions with complete visibility. Initially, the team thought about developing an app to allow the market to bid on the farmers’ crops. That idea failed even before inception cause they noticed the farmers only carry dumb phones, and the farmers were illiterate about the technology, and what is even worse is that some of the farmers don’t have phones to begin with. They changed their approach by developing multiple solutions and testing them in hypothetical scenarios in the field before committing to a solution. After various propositions and testing, they reached a solution where they give one individual in each village a dumb mobile phone and sending the prices in advance as simple messages with live data insights to provide better visibility to all.

The experiment is an instance where Design Thinking actually makes sense and truly works once it is embedded within the organization’s culture. And as Chris Lockhead said, it is The People Problem, not the technique.

The post Misunderstanding the Purpose appeared first on Discovering Change.

The differentiation is quite simple to explain. The organization is the legal entity that is created to present value to its surroundings. Of course, that includes all the resources, capabilities, functions, and services within the conferment of that legal entity. Now, once that legal entity starts to engage with external parties, by any means, then we begin shaping an enterprise at its working. So, a value presented to a client or a regulation imposed by a governing body falls among the enterprise work. Outside the enterprise boundaries, there might be entities that affect this environment, which belongs to an”extended-enterprise” scope. The extended enterprise includes all the relations between the parties scoped within the enterprise. Examples are how the anti-clients act against the organization’s benefits or how the competitors redefine their services for the organization’s clients. Defining such scope involves the analysis is hideous, and the returns diminish with more effort spent on it. Nevertheless, establishing such understanding is vital to capitalize on the extended enterprise health to ensure the organization’s existence.

One of the experts I admire, Tom Graves, uses this figure in describing the boundaries of an enterprise.

I would revise this diagram to rename the market as the enterprise, and the shared-enterprise as the extended (shared implies that there is already defined relationship while the external environment has a high number of entities that might interact with the organization under various circumstance). Nevertheless, this blueprint presents an overall snapshot of any enterprise regardless of its nature. In a sense, this image can be abstracted to demonstrate that the enterprise is nothing but a body that functions with defined input, internal processes, and output with somehow situational awareness.

Now, having such a simplified view of the enterprise, what points should expect some interaction?

Going back to Graves, he identified four types of interaction points that within any organization story-telling narrative:

• Inside-Out: This is the most apparent type of communication where the organization utilizes its value stream to present a value proposition to its client. Here the focus is on the kind of services the company provides to the enterprise. 

• Inside-In: here the different business units interact with each other in either the core value stream or the supporting function that the company needs to function as a whole (e.g., employee asking for vacation)

• Outside-In: most of the interactions here are initiated by the third party that will trigger some process within the organization. Tom limits the outside-in to the supplier/customer. I would argue that it includes any entity that has some sort of power over the organization’s purpose, e.g., regulators and anti-clients.

• Outside-Out: This one is one of the most ignored aspects of any enterprise or extended-enterprise definitions. This interaction is mostly related to what happens outside that might implicitly impact the organization. Thigs like competitors and disruptions are well placed here (even from a story-telling perspective). And due to the chaotic nature of such interactions, it is seldom ignored within any architecture work I have encountered (albeit from scenario planning in planning strategies)

Now, as for capturing the nature of all types of interactions and relating them to the architecture work. Well, there are ones that are obvious like value stream for inside-out, and there are ones that need improvising and refinement like the outside-out. But as long as such interactions are kept in checks, or the organization subconscious, then it will lead to a better understanding of how the organization can engage in ints soundings. 

The post The Enterprise Boundaries appeared first on Discovering Change.

Out the things that I have seen this carried out to the extreme are the marketing ploys advertised by the big consultancy firms. And among these that we abused to the extremes are Digital Transformation. I am guessing that anyone who is reading this is obnoxious about what it means, and for the ones who might read this after years to come might laugh about how ridiculous that time. You can start seeing this already with Gartner’s Top 10 Strategic Technology Trends for 2020. Nevertheless, consultancy firms will continue to advertise for this one way or another for the foreseeable future.

Among the ones who recently met consultants from a three-letter consultancy firm who were proud to show us a digital framework that should carry their clients, or transform them, to the new digital era. I have to admit that what they presented was good from an aspirational perspective. Nevertheless, they kept calling it framework over and over again in a way to fit the digital characteristics of a system into a very well constraint model. Now my concerns with what they presented are two-fold: Labeling it a framework and putting the digital as the overarching theme for it.

Let me start with the latter; the word digital carry less meaning with technology since one of the original authors who coined the term placed little emphasis on the technology, and more on the way organization should bring their business model for enterprise to become a digital one. The five elements are nothing but characters, from a system theory perspective, of an enterprise that could vary depending on the business and the market the enterprise works at. So, having a framework, which has a model and its boundaries, will never cover all scenarios or situations the enterprise face for a successful change.

As for the second concern, I have toward what was presented by the consultant is defining their model as a Framework. What they showed wasn’t a framework by any means. It was a nicely presented diagram with many circles here and there but without capturing the essence of what falls under the definition of a framework. And this one, I often fall into that mistake and calling something I draw as a framework.

From my simple search, a framework is nothing more than a methodology to govern and achieve change. And thus, any method should adhere to the essential theory background to safely claim that it is a framework. My research into the topic says that any framework should subscribe to either of the following as an approach of development: Logical Model and Theory of Change.

The Logical Model presents a way of how an effort or an initiative is supposed to work. It has many names like a roadmap, mental model, or rational. A Logical Model has many elements rightfully be called so. In short, it needs to have the following: purpose, context, inputs, activities, output, and effects. As for the Theory of Change, it is a more elaborated methodology that is very similar to the Logical Model but will dig deep into all possible pathways along with all outcomes, whether they are positive or negative. It presents the rationale of how and why a change should happen if a path is followed. You can indulge yourself in these social examples to get familiar with it.

I genuinely wish that digital transformation is something that we can model and practice. I want to it is transparent and beneficial. But without understanding the underpinning principles of such hype, this one or the next that we will have, no a so-called framework or model could carry the burden for everyone.

And as George Box once said: “all models are wrong, but some are useful.”

The post Frameworking It! appeared first on Discovering Change.

The thing about that response was that everyone in that room seems to agree about the existence of an unseen disjoint that we tend to design and the reality of the actual project of the design in the real world. It never matters of how compelling and useful the PowerPoint presentations, convincing word documents, how it is elegantly presented to top management. The reality that taking those artifacts and mobilizing teams and budgets to implement and deliver them will tend to fail to reach all objectives to some extent or another. And when things fail, then it is back to the drawing board while picking a scapegoat to take the hit.

I had seen this happening to me when I was a mere developer who is tasked with modeling UMLs for projects and then using tools and IDEs to generate well-structured code files and interfaces to be populated by business logic and processes. And do you know what? I, as well as my peers, modified much of the code structure to a level that resulted in mess-ups that didn’t have any resemblance to those UML diagrams. And I ended up with such an inconsistency between the architecture and the actual implementation that forced me to lie to my management and to say everything is a-okay. Because hey, it is all about what works and functions and not we keep in files and documents.

The design and delivery paradox is real, and there is no way running from it. Yes, everyone is moving to an agile model at an organization-level (it worked for those geeks and the software they develop, so why not implement it at the business operating level). But it is still finding hard spots to land in. And even with permitting an organizational growth with an agile and product-focused mentality, it always doesn’t resolve the paradox of taking the business aspirations and objectives and translating them into an adjusted operating model that doesn’t deal with producing code every time a scrum team plan for a sprint.

The complexity of systems, whether they are as complected as running a country or simple as managing a household, implies dealing with an unlimited number of knowns and unknowns. This makes it impossible to ensure an accurate representation of a system from the idea of its inception to the level where it runs within the world. Thus, any design should include many characteristics ensuring its flexibility toward dealing with a world that is chaotic by nature. 

The post The Concept and Realization Paradox appeared first on Discovering Change.

I have engaged in many enterprise architecture initiatives where the sole purpose of projecting the future based on the current business needs. I spend a couple of weeks or months in understanding the business, drafting its architecture, finding systems that realize the architecture, and then proposing a road map to reach that said future. But guess what, I have never seen anyone realizing that future, aside from core system development. And after all of those experiences, I believe that there might never be a perfect situation where the future is realized according to plan. It is like Marx said: “Men make their own history, but they do not make it as they please; they do not make it under self-selected circumstances, but under circumstances existing already, given and transmitted from the past.“

So what makes any prediction impossible to achieve? Well, it is the fact that we are living in an ever-changing world; flaps of butterfly wings can cause the weather change around its surroundings. But let’s scale it down and look into it from a business perspective, what causes our expectations and planning to fail continuously? One thing is that people tend to weave expectations based on their narrow experiences and desires. This is human nature and will never change whether we liked it or not.

Another thing is that people change and organization remains, that is if they don’t collapse, get bankrupt, or merged. What planned placed in a couple of months back might be refactored due to new management in place. It takes a couple of clicks from the organization chairman to change the whole management personnel and to retract and develop new strategies.

Markets, or extended enterprises, play the most crucial factor that wipes the whole organization’s ambitions and actions. Things like having a new competitor entering the market, a vendor leaving the market, new regulations, or the lack of it, and the presentient of anti-clients can destroy years of the organization effort in no time. Just a new technical innovation can render the organization value proposition to an absolute state.

 So among the many challenges foreseeable or unforeseeable, how should a business plan for its future? I tend to suggest a couple of points for my clients follow as a prelude to any planning activity:

• Be adoptive: The fine ingrained element of any business in this era is to structure itself to become adoptive to any charges imposed. I know the term agile is much better to describe the situation, but that term is widely overused to the point it is becoming a marketing ploy. 

• Utilize strategical scenario planning: Among the strategy discipline, there are the processes of developing multiple possible scenarios that occur to disrupt the strategy and what are the mitigations plans at hand. Of course, I will place an empathizes on the mitigations cause many of the best clients I have met don’t elaborate on the mitigations if, with the stroke of luck, they do have the scenarios at hand.

• Reduce expectations: This one is quite clear as the worst enemy of a man is himself. If you have set among shareholders or their CXOs, you will often see them congratulating themselves on the idea that they just brought at the table, and the remaining part is to translate those ideas into projects that real money.

• Follow a more lean organization decision making and actions: I tend to set the Chinese CCP governing model as an example for such point. Once the CCP decides on its strategical direction, it will cascade each of the objectives to every state head in China, and the administrator has full autonomy on how he/she could achieve the goals (Centralized decision making and distributed delivery mechanism). Of course, this is set with a robust governing model to ensure that no one jeopardizes the whole organization.

•  Follow the Value: This one is quite clear, but never have I seen organization backtracking on how the value is created. Any decision should be associated with the value proposition the organization provides to its end customers. Let all the plans explicitly state its role in enhancing the value proposition to place a compass on moving the enterprise. 

The post Fooling the Future! appeared first on Discovering Change.

But I have witnessed many times that this framework tends to fail miserably, and people immediately abandoning it due to reasons in understanding the organization’s aspirations and then capturing it through the Balance Scorecard. This eventually will limit the use of the Scorecard KPIs to become part of the operational dashboard.

Typically within the board member’s meeting, the CEO will be bombarded with the shareholder’s concerns. No matter what toolkit is used to capture and convey the strategy, the shareholders will eventually abstract their desire into their aspirations and goals. And then sideline some of those demands as initiatives without fitting it into an overall scorecard framework. I know everyone wants to add the “increase revenue” or “decrease operating cost” objectives within the financial perspective, but at the end of the day, the shareholders will always ask for those, in particular, every time they sit with the organization’s representative. This limits the objectives in all prospective into predefined set objectives that might never change. This becomes something like fishing fishes from a small pond; no matter what you do, you will get the same objectives every time. Now what the shareholders want to see, along with the KPIs, are the status of their specific demands in relation to the cascading KPIs from the strategy and how it feeds into an overall view of the organization’s achieved goals. This eventually makes the KPI as an internal tool to assess the Organization Performance rather than the Enterprise Performance (the difference between the two is subtle).

Also, I have seen that the momentum in trying to get the Scorecard to succeed within the first couple of tries becomes a burden to the business that reaches a level of neglect by the bottom line of business. Trying to teach everyone the importance of the KPIs will go in vain if the strategy is missing to think of the enterprise as a system with its complexity and unpredictability (the System Thinking and Engineering theory has plenty to learn from). The bottom line of business doesn’t care that much about the overall strategy as long as he has his own personal and professional goals met. Even middle-management who are busy in ensuring the business continuity and fighting their political battles might give little to none for understanding and contributing to the Scorecard. I have seen many saying they don’t care about those KPIs, but if it is cascading, then we can find away.

I know there is a need to capture the performance of the organization, and the Scorecard framework is a great tool once it is functioning. But I am not seeing it succeeding within the people I met. I don’t know if it is related to the culture or immaturity of the local enterprise, but I feel there is a need to associate the Organization Value to the Scorecard and anchoring the KPIs into the Value. I am throwing ideas out of my head, so my statement might not make sense; nevertheless, complicating the organization by yet another management will do more harm than good.

The post Making Enterprise Performance Useful appeared first on Discovering Change.

Since then, we have crossed great heights and leaps. We witnessed the disruption of the internet and mobile. New trends in merging the business with IT; the implications of mature technology capability, and the criticality of data and cybersecurity. All of those changes and disruption caused the business to react and adjust its expectations and requirements for the resources that deliver such capabilities. So, newly graduated were higher to specialize and work on those niches, and the industry further helped by brining very complex and sophisticated enterprise solutions that all the time in the world to understand. So we started hearing about the Data Analyst, Front-end Developer, and User Experience all of a sudden.

And with that divergence, the old people who founded and run IT departments during the 90s and 2000s suddenly found their selves very old to accompany the change as old systems started to be decommissioned in favor of the new trends. Those people were forced to either manage the transition, antecedently, or thrown in a supporting position that killed their career. They are now absolute, unrecognizable, and unwanted.

I was recently was with a client who was proud of his IT department where the oldest guy they have was of 35 years old. I know most of the people in our local culture, set aside the IT industry, want always to pump new blood in the business. But it should never reach the point where people of high expertise and knowledge are set aside when moving forward. There is a lack of diversity in the new IT environment when it comes to age. Everyone wants the 20 years old, rightfully so, but there must be a place for an expert with 30+ experience.

People who worked for the longest part of their lives have something the newly joint doesn’t have, and that is knowledge. And knowledge can’t be gain without mistakes within the path. You have those people who could say it will not work because it has flows; not energetic younglings who will kill for doing something to impress others.

I genuinely wish this trend slows down. Like what our culture has taught us is to respect the elders. Cause we will eventually get old, and we want to be treated with respect when we become the elders in the business environment.

The post No IT for Old Men appeared first on Discovering Change.

So when I first started seeing Architectural Thinking Association post within my LinkedIn profile, I didn’t give it that much of focus or interest. It wasn’t until I saw a post announcing that Mike Rosen joining the leadership that I started to put some excitement into the association. Also, for those who don’t know who Mike Rosen is, he is the founder Business Architecture Guild that genuinely establishes a great framework to close the gap between the business and operating model of an enterprise. So looking into the leadership page you could see Milan Guenther, who is the founder of the Enterprise Design Association, which tries to bring the design thinking practices into architecting the enterprise.

Again, the leadership page doesn’t include any tech-savvy personnel which I hope will help the association to defer the IT view of the enterprise and focus on the business as a whole and its interaction with the environment. I know their white-paper detour toward the technical aspects of the enterprise, scanned it and didn’t read, but this association is very new (I guess late 2018) and I hope things will change with the new joining members. I will read their available content for the time being and will try to summarize their approach within a short time (If only I could buy time!). So until then, I wish Wolfgang Goebl all the best luck and hope I see more content from them.

Edit:

Like usual, I prematurely judged that the architectural thinking framework is somehow technical. But I skipped the most important part of the whitepaper Which is starts on page 7, ya stupid me.

So this architectural thinking framework is somehow a lightweight EA that focuses on the business architecture at its heart rather than defining the domain as an amazonian jungle. The framework centers around four pillars:

• Architecture Model, or the metamodel.

• Architecture Maps.

• Architecture Principles.

• Integration Points

So the metamodel is focusing on very abstract models that represent the business in two forms (capability and value streams), data (information concepts), and the technical aspects (Application and Technology). From the first look, it seems like a very high-level Archimate notation without digging into the 50+ models it has.

The Architectural maps encapsulate a couple of views and diagrams that are agreed upon in most EA practices, like strategy maps and lvl2+3 value streams.

The architecture principles are the same that are agreed upon in most EA practices which I have my concerns about, but that is for another post.

And finally, the integration points serve as discrete relationships between the framework and the various models in the enterprise (business or operating).

In its current form, this seems like a straightforward but practical approach to a minimum set of artifacts to simulate a foundational EA practice for the enterprise. But there is shallow involvement from the community at the moment which I hope would be resolved with time.

The post Architectural Thinking appeared first on Discovering Change.

At the time, the 2008~09, I was working as a low level of technical and delivery personnel. So when my manager tasked me with bootstrapping the enterprise architecture team, the first I did was to Google the term so I can copy the templates and fill them up. Hey, everything was one step or another from my technical incubated mind. But boy, was I hit by a wall within the first hour or so from searching. It was like I was overwhelmed by oceans of information that didn’t add up. So, in trying to stay at my comfort zone, I went back to my manager begging to remove me from this nightmarish thing that was assigned to me only to be responded that it was great for my journey and my experience (the classic bait and switch). Well, I tried again and again but to less success that I would expect. Ya, things changes since that time but the essence remain the same, and that is CIOs, CTOs, and CxOs see themselves in a position with high technical entropy where randomness in technology is the norm and start researching to end up with a Gartner article or a consultant assessment that Enterprise Architecture will fix this problem and enable high level of assets re-usability and technology utilization.

I am guessing this scenario has and is happening to many organizations and enterprises. And what is worse is that once an EA is booted in a place, management will see it as the unicorn that will solve their all of their problems, and to be faced with overestimating the value realized and underestimating the level of commitment and resources needed to succeed (depending on what success is actually is). Eventually, such an initiative will be scrapped or placed on life support to be later revived by other management due to the problems that initially started the whole initiative in what is similar to business dementia!

And what is worse is that the EA office becomes like an archiving business unit that its sole purpose is to document, graph, catalog, built tables and matrices of any change that happens to the “Technology” with links to the business roots that caused that change. And to be later trophied by the EA office sponsor as the black wizards that can decide on the fly on the validity of the ideas and initiatives through they were instructed by the said manager on the what to say beforehand.

Look, I am not saying this as a touch of sarcasm but rather as things that I have seen and anecdotally heard many times. It is truly a sad state that we reached, and I yet to see, locally, a good and functioning example of a unit that truly fulfill its purpose and promise! And what is worst is that till this day and people get confused about what an EA is. At least twice this week, I directly heard from clients that they want to develop an Enterprise Architecture without mentioning what the mean. I reply on both occasions on what they want to get a reply they want something like a blueprint of how their IT looks!

Enterprise Architecture is a damn journey, not an initiative or a project delivered by a consultant firm relying on the clients’ ignorance. This journey purpose is not to capture and develop some artifacts to demonstrate it to management without any incoherent value, it is a journey that tries to make sense and context out of any change in the enterprise from the point where the aspirations change into strategies until the point there is a change in the operating model and its supporting resources whether people or technology. It has its roots in the system thinking and planning theories and lately incorporating some design thinking practices.

I will try to elaborate on this subject along my journey, and hopefully, I could formulate my language and concepts to describe what an EA is.

The post Making a Case for Enterprise Architecture appeared first on Discovering Change.

As I was sitting with a representative from one of the big four and discussing a mutual opportunity, he started to talk about digital transform this and digital transform that. In which he took the comfort to describe the essence of digital transformation and stated that “at old times the employee sits in front of a computer to do his work; but now he could use a computer, a tablet, or even a phone to do the same thing!”. I know I become a little bit sardonic when dealing with people, and for sure I know I spell more wrongs than right, which is why I tend to talk a few words when confronting key clients. However, having someone describing an omnichannel engagement as an aspect of digital transformation is purely wrong. The same happened with a CTO (Chief Transformation Officer and not Technical) when he describes the digital transformation the in his agency and how BPM will enable the change, I was like ahhh but…. or somewhat ok ya sure whatever you feel right for your situation. Cause at the end of the day we are arguing with less scientific foundation than any other domain, and instead, we are treating it like any other marketing gimmick (aside from one aspect I will dive into it later on).

Another guy whom I discussed with from another local consultant group stated that digital transformation is capturing the customer journey and pointing the voice of the customer (VOC) and voice of business (VOB) and then resolve these issues with a digital mindset, although I don’t comprehend that meaning. So it becomes just another User Experience Journey (UX) with an extra step to solve the issues rather than capturing them.

The thing about digital transformation is that there is not even a single institute with a well clear definition that people agree with. It is much like the Service Oriented Architecture (SOA) and Enterprise Service Bus (ESB), ya people know them and know some of their characteristics, but no one can give you the complete answer for it; it is a buzzword at best, and anyone can interrupt it to suit his/her story.

So how I would personally define digital transformation? Personally, digital transformation is all about the people and unparalleled change in behavior that is associated with the reliance on technology as a medium to exchange value. In his book “The Digital Transformation Playbook: Rethink Your Business for the Digital Age,” David Rogers explores the change in more details and to later define five critical domains that changed the game and influenced the business to transform and to accommodate the behavioral change. The factors are:

• Customers: move from one directional communication to bidirectional communication and its reciprocal effect on the relationship.

• Competition: previously, businesses compete over a segment of the market, which caused the impact to cascade to become something like Pepsi vs. Cola. However, now, to survive, companies have to compete in areas while collaborating in other areas to gain competitive advantages (Apple Music in Google Play)

• Data: previously data was of marginal importance, while in this era, the information is the king and harnessing the data across the customer journey will provide you with insights that give market advantages over competitors.

• Innovation: At the pre-internet era, getting feedback on a new product was a lengthy process with strenuous activities to accomplish; that is why product development requires enormous resources and time to develop. At this stage, with customers at the front of the value proposition, innovation should be fast-paced with much experimentation at hand (Design Thinking anyone?)

• Value: your value should be adaptable to change in customers preferences. The access to information allows the customer to customize and tailor a value up to his likening.

Now these elements or domains are more into understanding the market and its trend, and other publications might contradict with the assertions (A business expert wrote the book after all), so how would I communicate the concept to my clients? I ask them a simple question? Well, you change aspects of your business model? If they answer by yes, then that is a transformation. However, if they say no, then I would call it digitization.

The tricky question comes into mind, digitization could change an element of the business model, so should we call it digital transformation? Well, I tend to answer from my experience that if more than one element is changed, then I would qualify it as digital transformation, but there should be a reciprocal effect on the overall business model (vendor digitization altered the value proposition) otherwise you just did some optimization.

The post Hyping for Digital Transformation appeared first on Discovering Change.

In short, Moore hypothesized that any technology since its inception until it is decommissioned would follow a specific pattern where a community will start using the technology for niche use cases until it becomes mainstream. However, as Moore observed, there is a critical point in time when a technology expectation becomes so inflated that there is a chance the technology shortcoming become aperient and early adopters might abandon it in drove for other alternatives. That time in the lifecycle is the most crucial and impactful period that can kill the technology or fly it away to becoming mainstream. If you look at any failure in any field technology that got much hype, hello Segway, you will remember all the promises of clean transportation for the inner cities which failed to deliver on the promises that people built on it.

So where is risky from the customer side about the chasm from a business perspective? Well, the chasm represents the uncertainty of the technology, what exactly does it do? Blockchain until a couple of months back was in this stage where we know the technology we know it will go somewhere, but we don’t know how it will fit with our value proposition. Let alone most businesses synonym the technology with Bitcoin, which is nothing but utilization of the concept, for them, Blockchain is something that does something, but we don’t understand it. Now the risky part comes not from the lack of experience but from the business consultancy groups that prey on the clients’ ignorance about it. Consultancy groups are notorious for capitalizing on the chasm and will advocate for it to get those sweet contracts. Cause if you are not an early adopter then surely your competitors will gain market benefit once they adopt the technology. It doesn’t matter if we cross the chasm or not, as long as the consultancy subjected its narrative and expertise on the chasm to gain more engagements. If you could go back 15 years back, you would remember that one chasm was web portals were overpromised and how it would ease the development and delivery of competing advantages; much of my effort at that time was spend on technologies and understanding them then throwing all the business logic in a propriety technology that was very complex and chaotic. So look where the web portals went from there? Yes there are still portal products (now called Digital Experience Platform, ya lets throw another makeup layer to it) but the whole development process has significantly shifted from portlet development, I will never forget jsr186, into having a platform that consumes APIs and renders them. So in effect, even WordPress could be considered a Digital Experience Platform!

So what exactly should someone, or a business, do when facing the chasm? Initially, I would say it is to understand what the chasm is. The chasm is nothing more than the period that the technology proves itself for successful cases. Every technology or product has passed this phase to become a mainstream and then a utility and commodity (look at Linux). The second is, always treat this caution, don’t put much investment in it, experiment, experiment, experiment, and develop your use case and internal capability if the technology is proven through experimentation. Also, if you were a business that doesn’t have the human capabilities, then tread lightly with consultancy groups, and try to start small with failure in mind.

The post Chasing the Chasm appeared first on Discovering Change.

But who guessed that The Open Group, the same ones that brought TOGAF, has proposed ArchiMate, a modeling language, that represent a very lightweight EA framework? Before talking about what I like about ArchiMate, let’s go back to the man himself who first coined the term Enterprise Architecture, John Zachman.

When Zachman first proposed the Enterprise Architecture, he stated that it is a framework representing the fundamental structure of Enterprise Architecture. Or in other terms, an EA is an ontology of the organization. So you want to know how one thing is connected in the grand scheme of things. That was impossible with TOGAF in its purest form, and even with specialized tools, it is very hectic to have one view showing the enterprise-as-a-whole.

So what ArchiMate has to do with the previous paragraph, well it is a straightforward graphical modeling language that captures 80% of the business components and artifacts (well that is what The Open Group claims) that ensures the simplicity and practicality of modeling the enterprise. So, what does it to have with the EA? Well in its current form, ArchiMate can be fully utilized to capture the ontology of the enterprise and its behavior. Just as an example, the following is a simple model that captures the need for an ERP system:

In this simple, yet flimsy, model you could trigger precisely what are the motivation of the key stakeholder along with the course of account taken into consideration (Sparx EA didn’t allowed me to model some relations due to its inconstancy with the metamodel). So both of the CIO and CFO are looking into information consistency while the CFO has more drivers that translate into increasing the profitability of the enterprise. Now both of these drivers cascades into optimizing the different business units through a course of action and that is acquiring an ERP solution. This course of action will need to build the ERP capability that requires resources related to an IT Staff, ERP consultants, and ERP licenses.

Now, this diagram only touches two layers of ArchiMate that are concerned with enterprise aspirations and strategies. There are still layers for the business, application, technology, and the changes (or projects) which can be exploited to complement the view of any change. And while we are at it, I always suggest ArchiMate as the best approach to develop a solution architecture since it captures much of the changes required by any technical solution and is easily understandable by businesspeople.

Having such a model whenever there is change and including it into a central repository can develop such a great resource in capturing and understanding the complete picture of the enterprise. It might not be perfect but will ease the understanding of how to look and assess the enterprise as an actual whole.

The post ArchiMate as a lightweight EA framework appeared first on Discovering Change.

To be frank, I have never adopted this methodology with my previous government employer or even worked on it while I was actually working in Yesser; yes I had my input funneled toward the Government Data Reference Model (DRM), presumably, but never engaged with the Government EA office at that time due to my short stay with them. Nevertheless, I can’t enough express my open hatred toward anything that is celebrated as the de-facto standard for Enterprise Architecture since my initial confusion with TOGAF in the 2000s. But the NORA reference architecture has its own place in my heart as it affects much of the public sectors in Saudi Arabia.

In the simplest words, NORA is more a governance framework for the government agencies that were initially designed, as far as I know, as a “tool” to be used, as far as I know, to assess the maturity of the government agency to approving IT budgetary plans. It is compliant with TOGAF and FEAF and follows the classical Business Systems Planning approach as popularized by IBM in the 70s. So far so good! But this simple explanation of NORA doesn’t deliver the total catastrophic derivatives that it brings to the table.

First of all, have a look at their 400 pages document. And now consider this document got thrown at a poor soul by her pseudo-CIO of an agency with 200 employees! She will have the same shock that I got more than 10 years back. And the course of action, at best, will be to waste millions on a predatory consultancy firm that will just shuffle some of its decks and deliver it to the agency which will result in adding complexity to the enterprise. Oh yea, and that poor soul who found herself in that position in the first place, that is if she didn’t resign, will eventually that find herself as the Chief Enterprise Architect since no one ever saw the document. And the end result is waste of money, time, resources, talent, and more resent toward Yesser and anything Enterprise Architecture.

I have been interviewed multiple times for public agencies for the head of EA office just to take this NORA thing and make it compliant with whatever they have their just to please Yesser and later on win a prize or two at their bi-annual event.

Let’s an overview of the methodology steps:

Just from this figure alone, it will overwhelm you with so much stress that might break your mental stability for a day or two. Aside from the things your IT manages, NORA targets IT, so the meaning of enterprise is already lost, you get this thing that you must fit into your already chaotic schedule to get the blessing of Yesser and the chain of managers.

Look, I get it; we must have a common approach for EA architecture, but this doesn’t mean compositing multiple frameworks and word and throwing it in a document and calling it an EA methodology. Just an example, in step or phase 3, or whatever is called, you have the Analyze Current State, and under it, you have a SWOT analysis. Please excuse my ignorance, but how the heck can someone proclaim that an EA analysis needs a SWOT analysis? For what exactly? As found on wiki, I will not go into management and academic papers:

SWOT analysis (or SWOT matrix) is a strategic planning technique used to help a person or organization identify strengths, weaknesses, opportunities, and threats related to business competition or project planning.

https://en.wikipedia.org/wiki/SWOT_analysis

So, an IT business unit within a government agency THAT has absolutely no market competition and is more about digitizing some of the value delivery related to regulating aspects of the citizen/business/government relationship will do a SWOT analysis at the IT level rather than the strategical level! OK, I might misunderstand the SWOT concept, so let’s look at the reasons to do a SWOT analysis. So on page 100 (There is no apparent versioning number for this document but whatever), you will find the SWOT usage:

3. Carry out a SWOT analysis (Strengths, Weaknesses, Opportunities and Threats)

4. Compare some of the SWOT analysis with other external reports like United Nations, and direct comparisons with government agency in another country or region.

5. Document the SWOT findings and comparisons into the external environment analysis report.

Then what? What should I do with that SWOT analysis once I wasted a couple of hours if not days? Well the revelation is found on page 105:

This stage begins with the completed EA requirements, environment analysis reports (both current business and current IT landscapes) and the SWOT analysis report from Stage 3. Note that the EA Governance Committee may also provide additional strategic requirements at the end of Stage 3.

So I am doing a SWOT for the sake of just doing it!!!!! OK, I admit it, I am mentally challenged as like one of my close friends once said to me: “I don’t know how you graduated from the university.” So, please if anyone can help me in fitting this SWOT thing then please explain to me as you explain to a 3 years old and at that time maybe, and I say maybe, I can find a place in my tiny brain to process the logic behind it. Do you need some help from me, well here is a SWOT “template,” like you need one, that is included in the document:

Does this resemble anything related to an EA practice? Well, I leave this to you.

What do you want more inconsistency in the document? Well, let’s have a look at the maturity model, and specifically page 345. Here, NORA states that the maturity model for the agency EA is adjusted based on four pillars:

• Architecture development area

• Architecture process area

• IT Investment and acquisition strategy area

• Enterprise Architecture area

So among the four what seems out of place? Well, for sure it is neither the first two nor the last one. So, could anyone please tell me how the IT investment and acquisition has any relation to the EA practice? And BTW, it seems that they mistyped the acquisition while they should have instead used the term requisition. And if you dig deep enough in that pillar, you will find that it is all about templating RFPs and establishing procurement processes (Not going to lay there are multiple useful RFPs templates in their website but they don’t point you to them)

And to make the maturity calculation looks fancy and sophisticated, NORA suggested the following “formula” to obtain the maturity score:

And yet, I have to see some formulas in an EA outside the academic debates and EA KPIs.

Look, I know that I will get many replies to some of the points I outlined here, I can go on and on but it is a 400-page document, and I know many people who are experts in the EA domain worked on that document. I honestly admit that I am criticizing a lot and do less which makes an effort on that developing the document valuable. But at one stage during the development, someone forced the authors to add more until the document façade changed purely from light weighted EA model into this conglomerate thing that included many stuff related to IT but not the architecture practice.

I hope we see a revised document with more concise information and processes, and I am pretty sure that Yesser will have another look at this document in the short run. And until then, I petty the people who are forced to undergo this nightmare just to please their managers and Yesser.

The post NORA, What a mess! appeared first on Discovering Change.

“Don’t forget they will learn, and don’t forget recorders. Now, Chaplain, you’ve got a problem about Moties and Creation. The Empire has another. For a long time we’ve talked about the Great Galactic Wizards showing up and deciding whether to let the humans join, right? Only it’s the other way around, isn’t it? We’ve got to decide whether to let the Moties out of their system, and until that’s decided we don’t want them to see the Langston Field generators, the Alderson Drive, our weapons.. . not even just how much of MacArthur is living space, Chaplain. It would give away too much about our capabilities. We’ve a lot to hide, and we’ll hide it.”

The Mote in God’s Eye – Larry Niven, Jerry Pournelle

So back to the subject of business capabilities, If there were two business artifacts that I would say it is the utmost necessity for an enterprise to have then I would consider the business capabilities and abstract view of the value streams that define the value delivery with the proposition to the end stakeholders.

And as Chris Lockhart once mentioned in a blog post:

“If there happens to be, by some lucky stroke, a comprehensive business architecture at your company, you are in luck.”

He is not wrong at all, in fact having a ready to inspect capability map will give a direct insight into the organization business model and some aspects of the operating model. So let’s have a look at a capability map according to Business Architecture Guild:

This is the same one that I discussed in my previous post but with more information added. This information corresponds to an assessment we did to our imaginary small enterprise where it shows the effectiveness of all of its capabilities. Having this at any strategical meeting will immediately refocus the talks and concentrate them on what our enterprise does well and where it is missing its competitiveness compared to competitors. So instead of funneling the budget toward the supporting capabilities which doesn’t add too much in terms of competitiveness, the funds and budgets can be focused on those capabilities that actually give you leverage over anyone else (What the BizBok says laser-pointing precision of budget allocation).

Also, this map will provide a better insight on what capabilities can be outsourced to other strategic partners where that said capabilities are performed much at much better performance with less cost compared to building and maintaining it internally. Moreover, initiatives and projects conflicts could be avoided if more than one initiative alter or interact with one universal capability. Now, you have a much better resource utilization in the organization with a view of affected business capabilities at hand. Added to that, we now have one common vocabulary on what the enterprise does, so ideas and dialogs are exchanged with the utilization of the enterprise dictionary.

Another use for having business capabilities is the impact analysis if such mapping between the capabilities and other aspects of the enterprise exist. I demonstrate such mapping as follows:

With the well-defined capabilities, an architect was able to directly map and align the business capability to the corresponding application that automates the said capability (in this case ERP solutions). Now, this is a simple mapping that abstracted much of the extra info that resides (Thanks ArchiMate for the Derivation Rules). Now, in case we want to upgrade, for example, the SAP HR Policy Management and use the cloud alternative then we would have a direct insight on the capabilities affected and address the challenges and risks associated with the upgrade. More than that, we will see which business units utilize that capability and plan for better change management practices.

These are some of the simple stuff we could do with the existing capabilities maps, but till this moment I yet to see a local company that addressed and documents those capabilities. I know it is a lengthy process which takes months of meetings and workshops, but the advantages are evident. Maybe cause the enterprises are yet to embrace the holistic view of the Enterprise Architecture practice entirely and in particular the business architecture aspect (It is still in the Trough of Disillusionment phase of Gartner’s Hype Cycle). And until then, I wish more and more enterprises do this to make at least it easier for consultant companies to translate the business into suitable enterprise solutions.

The post Another look at Business Capabilities appeared first on Discovering Change.