The Project Business Model Principles

This post is number eight in a series of ten about real life experiences of using business model thinking as a foundation for planning and delivering change. Writing this post I’ve had the help of a true friend and admirable colleague (Eva Kammerfors) whom I’ve shared many of the referred to business model experiences with. […]

Link Collection — May 26, 2013

  • You Are Not a Large Corporation — I don’t know a thing. — Medium

    Totally. Well, not the llamas.

     “You can define “success” without it being tied to quarterly shareholder reports or even income. It can be tied to the amount of days you can afford not to work. Or by how much you can donate to your favourite animal charity that rescues llamas. Or by how often you can work from the road.”

    tags: success

  • “So she posted her solution online, and then…” | johnstepper

    Good post by John Stepper. I’ve highlighted the issue I encounter most in enterprises: the quest for credit, as mandated by current performance practices:

    “People who are aspiring to make a difference will share their work online so others can use it and improve on it. Yet it’s a phrase you might never hear at work. Why not? And what can we do about it?”

    “I won’t get credit.” A more insidious barrier is when people feel their contributions won’t be recognized. Particularly in a management system of competitive ratings and bonuses, there is a heightened sense of internal competition. Feeling like you’re fighting for your share of a finite pie will grossly inhibit your willingness to contribute and collaborate.

    “And credit? This comes in several forms. Social recognition from relevant peers is often powerful enough to drive continued contribution. Beyond that, though, it’s the role-based community that knows about all the good jobs within the firm. When individuals contribute, they do so for their own reputation and their access to opportunities in addition to the good of the community.”

    tags: collaboration talent_management

  • 15. Ivan Poupyrev | Fast Company | Business + Innovation

    “Ivan Poupyrev had a theory: What if he sent a broad spectrum of AC current through everyday objects? Would those objects be able to sense touch? The answer is yes, and Touche is the sensor system developed by Poupyrev and his team at Disney to do it.

    Connect Touche to a living orchid and the plant’s entire skin becomes touch-sensitive just like a smartphone screen; attach it to a computer-music program and you can play the flower like a violin. Touche is compatible with almost any object you can grab–wooden tables, metal sculptures, water tanks, even breathing humans. Touche could make every square inch of Disney World responsive to touch–and open up a world of possibility for connecting objects to the Internet. “My long-term vision,” Poupyrev says, “is making the entire world interactive.””

    tags: innovation touch interactiondesign

  • The audacious plan to end hunger with 3-D printed food – Quartz

    “[Anjan Contractor] sees a day when every kitchen has a 3D printer, and the earth’s 12 billion people feed themselves customized, nutritionally-appropriate meals synthesized one layer at a time, from cartridges of powder and oils they buy at the corner grocery store. Contractor’s vision would mean the end of food waste, because the powder his system will use is shelf-stable for up to 30 years, so that each cartridge, whether it contains sugars, complex carbohydrates, protein or some other basic building block, would be fully exhausted before being returned to the store.”

    tags: 3dprinting hunger

  • How to Run IT at the Speed of Silicon Valley – The CIO Report – WSJ

    “a combination of technologies, management practices and cultural features that enable Valley technologists to work fast. These practices are used by their engineering and IT organizations.”
     
    “…Before companies become fast, they have to learn how to accelerate.  There are new skills to learn. But perhaps more challenging is the need to unlearn old ways. For example, traditional development practices, such as change control boards to oversee code changes, are inconsistent with rapid, iterative and agile practices. Companies that use both agile and traditional techniques must figure out how they will co-exist.  While CEOs may not completely agree with LinkedIn Chairman Reid Hoffman’s maxim, “if you are not embarrassed by your first release, you’ve launched too late!”, they need to support CIOs who, in their quest to create faster, more agile IT organizations, attempt to follow its spirit.”

    tags: IT acceleration

  • In the Programmable World, All Our Objects Will Act as One | Gadget Lab | Wired.com

    “In this future, the intelligence once locked in our devices now flows into the universe of physical objects. Technologists have struggled to name this emerging phenomenon. Some have called it the Internet of Things or the Internet of Everything or the Industrial Internet—despite the fact that most of these devices aren’t actually on the Internet directly but instead communicate through simple wireless protocols. Other observers, paying homage to the stripped-down tech embedded in so many smart devices, are calling it the Sensor Revolution.

    But here’s a better way to think about what we’re building: It’s the Programmable World. After all, what’s remarkable about this future isn’t the sensors, nor is it that all our sensors and objects and devices are linked together. It’s the fact that once we get enough of these objects onto our networks, they’re no longer one-off novelties or data sources but instead become a coherent system, a vast ensemble that can be choreographed, a body that can dance. Really, it’s the opposite of an “Internet,” a term that even today—in the era of the cloud and the app and the walled garden—connotes a peer-to-peer system in which each node is equally empowered. By contrast, these connected objects will act more like a swarm of drones, a distributed legion of bots, far-flung and sometimes even hidden from view but nevertheless coordinated as if they were a single giant machine.”

    tags: internetofthings iot ioe systems programmableworld

Posted from Diigo. The rest of my favorite links are here.

Towards Next Practice EA

A few weeks ago, @Cybersal and I met with @snowded to talk about enterprise architecture. He showed us a graph of the Complex Space, whose two dimensions were Evidence and Consensus. Dave has since posted a version of this graph on his blog.Source: D…

Some notes on NOTES

What is a narrative-oriented approach to enterprise-transformation? Why use it, and where, and how? And where did all this NOTES stuff come from, anyway? NOTES is, I admit, a somewhat-forced acronym for a way to look at business-change: Narrative-Oriented Transformation of Enterprise

Data Management 2: Subject Areas and Objects

<p class=”p1″><span class=”s1″>This is the second blog post in the Data Management series and we will dive straight in with a discussion about subject areas and (information) objects, often called Entities. We start with a high-level overview of the theory and then dive into ArchiMate modeling.</span></p><p class=”p1″><img alt=”Subject Areas and Objects. Data Management blog series” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130524_BasvanGils/Data-management-subject-areas-objects_424x283.png” style=”width: 424px; height: 283px;” title=”Data Management blog series. Part: Subject Areas and Objects”/></p><h2 class=”p1″>Theory</h2><p class=”p1″><span class=”s1″>A subject area model is used to differentiate between areas of interest from a data/ information perspective in the organization. These are called Subject Areas. Examples of subject areas are: customer, product, and supplier. This is not a new concept; it seems that it was introduced by James Martin in his books on Information Engineering in the late 1970s/ early 1980s. </span><br/>A Subject Area typically consists of 12-20 Business Subjects. These are the key areas of interest in the business domain. Simplifying slightly from the <a href=”http://www.amazon.com/Guide-Management-Knowledge-DAMA-DMBOK-Edition/dp/1935504029/” target=”_blank”><span class=”s2″>DMBOK</span></a> best practice, we use the concept of an Entity as a synonym for a Subject.<br/>Note that in fact we are talking about Entity Types rather than Entities (see the work of <a href=”http://www.amazon.com/Data-Reality-Perspective-Perceiving-Information/dp/1935504215/” target=”_blank”><span class=”s2″>Kent</span></a> for an extensive discussion of why this distinction is important). We focus on the type level, not the instance level. For purposes of readability, we will consistently use the term Entity rather than Entity Type. The following ORM diagram illustrates this point:</p><p class=”p1″><img alt=”Entity types related by means of a fact type” class=”left” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130524_BasvanGils/data-management-entity-types.png” style=”width: 202px; height: 110px; float: left;” title=”Two Entity Types (Person and Company) related by means of a fact type (“works for” with the inverse reading “employs”).”/>Here we see two Entity Types (Person and Company), each identified by their na,e. These are related by means of a fact type (“works for” with the inverse reading “employs”). The purple dot signifies the constraint that “each Company employs at least one Person”</p><p class=”p1”>The population of this scheme in terms of Entities is visualized by the supporting table. Here we see for example that the label “Bas” identifies an Entity of the Entitiy Type “P<span style=”font-size: 11px; line-height: 19px;”>erson”.</span><br/> </p><p class=”p1″><span class=”s1″>Business Entities are the ‘things’ we talk about in a business context. For example, the Subject Area ‘Customer’ would be decomposed in Entities such as customer, address, and purchase history, etcetera. </span><br/>One would typically make an ERD to show the relations between entities as well as constraints on these entities (for each order the customer supplies a shipping address and a billing address). This may be a bit too much at the architecture / ArchiMate level, but we should at least be able to tie in to an ERD.</p><h2 class=”p1″>Modeling</h2><p class=”p1″><span class=”s1″>In summary: we introduced and defined two concepts for information modeling that we will be using throughout this blog post series: </span></p><ul><li class=”li2″><span class=”s1″>Subject Areas, which are used to structure areas of interest from an information perspective,  for example customer, or product; and,</span></li> <li class=”li2″><span class=”s1″>Business Entities (or just short: Entities), which are the key concepts or “things” that are part of a Subject Area, e.g. for the Subject Area customer: address or purchase history;</span></li></ul><p class=”li2″><span class=”s1″>​</span>In this part we describe how these concepts could be modeled in ArchiMate. This makes it possible to integrate model support for Data Management into the overall Enterprise Architecture expressed in the ArchiMate standard. Also, tool support such as BiZZdesign’s modeling and analysis tool for Enterprise Architecture, BiZZdesign Architect, can be leveraged for Data Management.<br/><span class=”s1″ style=”font-size: 11px; line-height: 19px;”>It seems to make sense to model the Subject Area concept with the </span><span class=”s2″ style=”font-size: 11px; line-height: 19px;”><b>BusinessObject</b></span><span class=”s1″ style=”font-size: 11px; line-height: 19px;”> concept. In BiZZdesign Architect, we could add a profile to this concept so that we can distinguish them from regular </span><span class=”s2″ style=”font-size: 11px; line-height: 19px;”><b>BusinessObjects</b></span><span class=”s1″ style=”font-size: 11px; line-height: 19px;”> in the sense that they could have a different graphical shape. </span><br/><span class=”s1″ style=”font-size: 11px; line-height: 19px;”>Along the same lines: Entities should be modeled using the </span><span class=”s2″ style=”font-size: 11px; line-height: 19px;”><b>BusinessObject</b></span><span class=”s1″ style=”font-size: 11px; line-height: 19px;”> concept. This does not require any further profiles, except for cases where the model also captures other types of business objects (i.e., non-informational objects) and we want to be able to distinguish between the two types. Two challenges remain:</span></p><ol class=”ol1″><li class=”li1″><span class=”s1″>Entities have Attributes. It may be very important to be able to represent the fact that we distinguish between “first name” and “last name” rather than simply using “name”. Since ArchiMate does not have a concept for Attribute, we propose to simply use a </span><span class=”s2″><b>CompositionRelation</b></span><span class=”s1″> to decompose </span><span class=”s2″><b>BusinessObjects</b></span><span class=”s1″> into its attributes.  Domains, cardinality and optionality are not modeled at the ArchiMate level.</span></li> <li class=”li1″><span class=”s1″>Many organizations choose to explicitly model meta-data about Entities. For example: definition of the concept, relevant business rules and legislation, stewardship (as we will describe in a later posting) and so on. It seems to make sense to use the ‘</span><span class=”s2″><b>Meaning’</b></span><span class=”s1″> concept for this. However, this quickly becomes tedious and will crowd the model. Also, some meta-data is represented by the fact that </span><span class=”s2″><b>BusinessObjects</b></span><span class=”s1″> are linked to other ArchiMate concepts in the model. We will get back to the meta-data discussion in a separate post! </span></li></ol><p class=”li1″><span class=”s1″>​</span>To provide a link with the design level, it makes sense to relate Subject Areas to more detailed ERD models. To do this, we have recreated the basic Chen ER diagramming notation as a separate meta model in Architect which allows us to do the following:</p><ul><li class=”li2″><span class=”s1″>A Subject Area as modeled in the ArchiMate world </span><span class=”s3″><b>is refined in</b></span><span class=”s1″> an ERD view</span></li> <li class=”li2″><span class=”s1″>An Entity as modeled in the ArchiMate world </span><span class=”s3″><b>is equal to</b></span><span class=”s1″> an entity in an ERD view</span></li></ul><p class=”li2″><img alt=”Subject area and entity modelled in ArchiMate ” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130524_BasvanGils/Data-management-ArchiMate-model-package_599x274.png” style=”width: 599px; height: 274px;” title=”Subject Area as modeled is refined in an ERD view in ArchiMate. An Entity is equal to an entity in an ERD view in ArchiMate”/></p><p class=”li2″><span class=”s1″>​In the next posting in this series we will describe how entities are realized in applications. As always: if you have questions or suggestions, please drop us a note. Stay tuned!</span></p>

Categories Uncategorized

SCRUM at the center of Enterprise Architecture

A couple of days ago a tweet from John Gøtze cought my attention

EA can be agile and scrummilicious, says @soerenstaun in guest lecture at the IT University of Copenhagen.
— John Gøtze (@gotze) 29. April 2013

And my reaction to it was it should:

“@gotze: EA can be agile and scrummilicious, says @soerenstaun in guest lecture at the IT University of Copenhagen.” I say it should!
— Kai Schlüter (@ChBrain) 29. April 2013




(c) Tom Graves

To explore this a bit further now finally this blog post. When I am tasked to implement Enterprise Architecture first time or to improve an existing capability then I put an agile approach in the core, preferable SCRUM. There is various reasons for this. To explain the concept I borrow the SCAN framework from Tom Graves, here in particular the post Sensemaking – modes and disciplines.


In my implementations of Enterprise Architecture activities I focus on the problem space Ambiguous and Not-Known. Ambiguous problems can be quite well solved with SCRUM, where “the whole is greater than the sum of it parts”, Aristotle. Agile approaches which do not put the team into the centre of their methodology do not seem to work as well in this problemspace. The identification to which quadrant a problem and the corresponding solution belongs is in my mind always an ambiguous problem, due to the scope of Enterprise Architecture, trying to cover the whole [which is more than the sum of its parts].

Problems which belong to Simple or Complicated I usually hand over as fast as possible to better suited teams or individuals, while the ambiguous problems I keep inside of Enterprise Architecture. The Not-Known space is total different and typically I focus on finding the Innovation which emerges here instead of trying to force it. I believe that Innovation can be easier found peripheral and not really by looking for it centrally.

By implementing SCRUM in the center some key elements needs to be in place to succeed. One of the most crucial elements is the Chief Architect, be it the official announced Chief Architect, or a manager (e.g. CIO) who is filling that role. The Chief Architect is the one who gets the SCRUM role Product Owner assigned. And here typically some effort and attention is needed to secure that the Chief Architect is focussing on delivering into his role as Product Owner instead of doing the actual work. The work should be done by the SCRUM team (or Pigs).

The most important element here is to create an environment in which the team utilizes the strenghts of each other. And here also lies one of the biggest challenges, because most Enterprise Architects have been grown from technical roles and have been survived quite some selection criterias till they have become an Enterprise Architect. Statistically I observe a high amount of heroes or divas, who are quite biased that an Enterprise Architect and especially they themselves are the crown of the evolution. Concepts like the Peter Principle support that thinking even more. 🙂

The only role which is fairly easy to fill is the SCRUM Master. Just take any good SCRUM Master who is NOT knowing much about Enterprise Architecture (preferred) or willingly not going into the content (sometimes hard, if the SCRUM Master is self biased believing to know better about Enterprise Architecture). So literally someone who only focusses on securing that the process runs.

This is of course not always easy to implement, but it is my main target to achieve. And I continue developing a team towards that target, till it is achieved. And when achieved the speed can be even increased, because then the environmental problems are solved and the focus can be on the delivery of good Enterprise Architecture Services, which is a post I also plan.  SCRUM helps me to deliver to my main objective. Enterprise Architecture and especially my approach GLUE is about People first:


Comments as always more than welcome.

SCRUM at the center of Enterprise Architecture

A couple of days ago a tweet from John Gøtze cought my attention

EA can be agile and scrummilicious, says @soerenstaun in guest lecture at the IT University of Copenhagen.
— John Gøtze (@gotze) 29. April 2013

And my reaction to it was it should:

“@gotze: EA can be agile and scrummilicious, says @soerenstaun in guest lecture at the IT University of Copenhagen.” I say it should!
— Kai Schlüter (@ChBrain) 29. April 2013




(c) Tom Graves

To explore this a bit further now finally this blog post. When I am tasked to implement Enterprise Architecture first time or to improve an existing capability then I put an agile approach in the core, preferable SCRUM. There is various reasons for this. To explain the concept I borrow the SCAN framework from Tom Graves, here in particular the post Sensemaking – modes and disciplines.


In my implementations of Enterprise Architecture activities I focus on the problem space Ambiguous and Not-Known. Ambiguous problems can be quite well solved with SCRUM, where “the whole is greater than the sum of it parts”, Aristotle. Agile approaches which do not put the team into the centre of their methodology do not seem to work as well in this problemspace. The identification to which quadrant a problem and the corresponding solution belongs is in my mind always an ambiguous problem, due to the scope of Enterprise Architecture, trying to cover the whole [which is more than the sum of its parts].

Problems which belong to Simple or Complicated I usually hand over as fast as possible to better suited teams or individuals, while the ambiguous problems I keep inside of Enterprise Architecture. The Not-Known space is total different and typically I focus on finding the Innovation which emerges here instead of trying to force it. I believe that Innovation can be easier found peripheral and not really by looking for it centrally.

By implementing SCRUM in the center some key elements needs to be in place to succeed. One of the most crucial elements is the Chief Architect, be it the official announced Chief Architect, or a manager (e.g. CIO) who is filling that role. The Chief Architect is the one who gets the SCRUM role Product Owner assigned. And here typically some effort and attention is needed to secure that the Chief Architect is focussing on delivering into his role as Product Owner instead of doing the actual work. The work should be done by the SCRUM team (or Pigs).

The most important element here is to create an environment in which the team utilizes the strenghts of each other. And here also lies one of the biggest challenges, because most Enterprise Architects have been grown from technical roles and have been survived quite some selection criterias till they have become an Enterprise Architect. Statistically I observe a high amount of heroes or divas, who are quite biased that an Enterprise Architect and especially they themselves are the crown of the evolution. Concepts like the Peter Principle support that thinking even more. 🙂

The only role which is fairly easy to fill is the SCRUM Master. Just take any good SCRUM Master who is NOT knowing much about Enterprise Architecture (preferred) or willingly not going into the content (sometimes hard, if the SCRUM Master is self biased believing to know better about Enterprise Architecture). So literally someone who only focusses on securing that the process runs.

This is of course not always easy to implement, but it is my main target to achieve. And I continue developing a team towards that target, till it is achieved. And when achieved the speed can be even increased, because then the environmental problems are solved and the focus can be on the delivery of good Enterprise Architecture Services, which is a post I also plan.  SCRUM helps me to deliver to my main objective. Enterprise Architecture and especially my approach GLUE is about People first:


Comments as always more than welcome.

Farewell, Journal

The May number of the Journal of Enterprise Architecture is now available to AEA members. This number contains a good blend of fine articles: Editor’s Corner: John Gøtze Architect in the Spotlight: Chris Bird Towards Enterprise Architecture-Infused Organizations By Bjorn Cumps, Stijn Viaene, Pascal Dussart, Joachim Vanden Brande The EARScorecard – An Instrument to Assess the Effectiveness […]

NOTES – putting it into practice

How do we use an narrative approach in enterprise-transformation? What’s different about it, in real-world practice? How does it work? In the first post in this series, I introduced the core ideas for NOTES – Narrative-Oriented Transformation of Enterprise (and)