Link: http://tracking.feedpress.it/link/16381/5654694
By DevOps Digest
The key to achieving business agility – not simply success with Agile approaches – is Agile Architecture: a reinvention of enterprise architecture that focuses on developing change as a core 
competency in the organization.
Jason Bloomberg
President, Intellyx
Read the entire article at http://www.devopsdigest.com/agile-development-4
Link: http://tracking.feedpress.it/link/16381/5693524
By Shane Hastie
ForbesのJason Bloomberg氏は、イベントの内容を要約した“Digital Transformation Requires Enterprisewide Agile Transformation”という記事の中で、イベントについて次のように述べてい
る。
先週ニューヨークで開催された ICAgileの第1回Business Agility 2017カンファレンスにおいて明らかになったのは、アジャイルがテクノロジの枠を飛び越えて、ソフトウェアの世界の外へと拡大したということです。企業は今、アジャイルプラクティスの採用範囲を組織全体へと拡げることで、自らを飲み込もうと荒れ狂う海域の航海を成功に導こうとしているのです。
Read the entire article at https://www.infoq.com/jp/news/2017/04/business-agility2017-success
In “Architecture is Dying – Why EA and Agile isn’t enough to stop Shadow IT“, Barry O’Reilly writes for IASA, “an association for all IT architects“, that “architecture is dying”…
Barry expects though a backlash for saying this “horrible “truth“.
Yet, I agree
In “Architecture is Dying – Why EA and Agile isn’t enough to stop Shadow IT“, Barry O’Reilly writes for IASA, “an association for all IT architects“, that “architecture is dying”…
continuing from
Link: https://enklare.wordpress.com/2015/11/03/the-customer-card/
It’s never been as important to reach outside of the business as it is in the digital world of today. From an architects perspective it is vital to be able to connect the dots between what is servicing and who is being served. This little card is designed to help you go fast by staying small and keeping it nimble. The design of the card does some heavy lifting by tying the outside to the inside through services and value requirements.
This Customer Card contains an example to make it easier for others to use the template card.
When you should use this
What you should consider when you use this
License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
Download
You can download the presentation here
Related
Post change log
2015-11-03: Published initial post
Link: https://enklare.wordpress.com/2015/11/09/capability-map-patterns-l0/
Don’t be scared, level zero in a capability map is just a way to structure the map so that we have a consistent way of communicating. It’s really not that important if all you wish todo is create an excellent set of capabilities for your business. However if you are intent on changing the foundation of your business then level zero is absolutely imperative to get right. Capabilities and capability maps are not organization structures, they do however serve as a powerful instrument when one need to create an organization architecture, in fact they are best thought of as organizing structures.
Are these patterns better than any other pattern one may ask and the answer is that they are not. There is probably more than a enough patterns to this problem of layout if you Google for capability maps. It’s just that I’ve used these patterns a lot and have seen others use them and have found them to be highly effective to influence the future of a business.
Remember that any business capability map can be reordered into any of these patterns, so do not let the choice of pattern for level zero stop you from investigating what is important.
The system perspective is highly influenced by the viable systems model created by Stafford Beer and the OODA Loop created by John Boyd.
When you should use this
What you should consider when you use this
License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
Download
You will be able to download the presentation here.
Related
Post change log
2015-11-09: Published initial post
Link: https://enklare.wordpress.com/2015/11/11/the-digital-business/
The current situation
There is a huge gap in insight as to what a digital business really is. Today when I hear business leders talk about going digital it’s mainly revolving around four scenarios.
All four scenarios are valid efforts and should be taken into consideration as they will build a foundation for what needs to be. However this is not what defines a digital business.
Truly going digital means operating the business through a digital representation and this means that the models in the business repository has to (inter)face with reality.
The emerging situation
Principle #1: Don’t put anything in the repository to which you cannot attach a realtime data stream.
Why: All the things you have in the repository is a logical representation of something that is a real thing in a business perspective. Not collecting and displaying data from that real thing and associate that with the logical representation means that you really don’t have a clue about what is happening, what could happen and what will happen. To put it bluntly – you are just playing in the sandbox.
How: Attach the Customer, Financial, HR, Change and Production data streams to your repository, filter out the things that you need to display with the model element and put the rest on a query basis.
What: Use of complex event processing, analytics and decision support over the data in the repository means that early signs of change should be detected and action can be taken directly with a full insight into the consequence. Having this capability means that the business will become more efficient. On the inside you will have to redesign your workflows as they could now become automated by large and further the digitalization of the business.
Outcome: The business is agile, predictive and profitable in proportions never experienced before.
Link: http://it.toolbox.com/blogs/ea-matters/bimodal-agile-and-devops-70480?rss=1
…never mind IT, to survive, most our enterprises are rather bimodal. But I would no call them that, Bimodal enterprises, it sounds too clinical.
Link: http://it.toolbox.com/blogs/ea-matters/to-be-or-not-to-be-bimodal-70484?rss=1
IT is not really about investigating the emerging Digital technologies landscape, their adoption strategy and roadmapping.
Link: http://blog.opengroup.org/2016/02/03/the-unix-based-cloud/
By Harry Foxwell, PhD, Principal Consultant, Oracle® Oracle® Solaris continues to evolve as the foundation for critical private cloud implementations. As the premier UNIX® system in the IT industry, certified against The Open Group exacting standards for enterprise-level operating systems, … Continue reading 
Link: http://davidsprottsblog.blogspot.com/2016/02/going-beyond-defined-agile-methods.html
I’ve been spending nearly half my time in Philadelphia over the past while, and I just happened to have a spare Saturday yesterday, so I hightailed it downtown. I had two objectives – to explore the Museum of Art and to attend a Brahms concert by the Philadelphia Symphony Orchestra. One of the featured exhibitions in the adjacent Perelman Building caught my eye. It’s named, Work on What You Love: Bruce Mau Rethinking Design. I wasn’t sure what to expect; I certainly hadn’t heard of Bruce Mau before, but I am always interested in design and design methods.
The gallery is essentially laid out to be controversial, to challenge one’s status quo thinking. In a video, Mau says, “practically everything that we do is being designed or redesigned; if you think about the way that we live now our life from womb to tomb is a design experience. If we want a great life experience you have to design it.” Mau goes on to say his work is focused on allowing people who aren’t designers to have access to the power of design, in their life, their work, in their business. Giving people the tools to design their future in a highly positive way.
Almost at the door of the gallery is a huge exhibit detailing his “incomplete manifesto for growth”. And the manifesto principles look like a superset of the Agile development manifesto, but writ large, with vastly greater ambition. First there are 43 principles. What! I say to myself, how can that many principles be useful? But of course once you start reading you are hooked. The Agile principles are embedded, but there’s much more. Let me give you a taster:
1. Allow events to change you. You have to be willing to grow. Growth is different from something that happens to you. You produce it.
5. Go deep. The deeper you go the more likely you will discover something of value.
8. Drift. Allow yourself to wander aimlessly. Explore adjacencies. Lack judgment. Postpone criticism.
9. Begin anywhere. John Cage tells us that not knowing where to begin is a common form of paralysis. His advice: begin anywhere.
13. Slow down. Desynchronize from standard time frames and surprising opportunities may present themselves.
16. Collaborate. The space between people working together is filled with conflict, friction, strife, exhilaration, delight, and vast creative potential.
20. Be careful to take risks. Time is genetic. Today is the child of yesterday and the parent of tomorrow. The work you produce today will create your future.
22. Make your own tools. Hybridize your tools in order to build unique things. Even simple tools that are your own can yield entirely new avenues of exploration. Remember, tools amplify our capacities, so even a small tool can make a big difference.
29. Think with your mind. Forget technology. Creativity is not device–dependent.
31. Don’t borrow money. Once again, Frank Gehry’s advice. By maintaining financial control, we maintain creative control. It’s not exactly rocket science, but it’s surprising how hard it is to maintain this discipline, and how many have failed.
39. Coffee breaks, cab rides, green rooms. Real growth often happens outside of where we intend it to, in the interstitial spaces—what Dr. Seuss calls “the waiting place.”
41. Laugh. People visiting the studio often comment on how much we laugh. Since I’ve become aware of this, I use it as a barometer of how comfortably we are expressing ourselves.
These are just a sample. You get the idea. This is Agile for the real world. For those people that are stuck in the zone of religious adherence to Agile development methods this may be anathema. But it’s a wakeup call. Invent your own.
The complete list and much more . . .
Work on What You Love: Bruce Mau Rethinking Design
November 21, 2015 – April 3, 2016
AFTERWORD: I wonder to what extent these principles map to a variety of design disciplines? In fact surely all design disciplines are creative processes. Would this include musical composition? I see no reason why not.
Link: http://davidsprottsblog.blogspot.com/2016/02/going-beyond-defined-agile-methods.html
I’ve been spending nearly half my time in Philadelphia over the past while, and I just happened to have a spare Saturday yesterday, so I hightailed it downtown. I had two objectives – to explore the Museum of Art and to attend a Brahms concert by the Philadelphia Symphony Orchestra. One of the featured exhibitions in the adjacent Perelman Building caught my eye. It’s named, Work on What You Love: Bruce Mau Rethinking Design. I wasn’t sure what to expect; I certainly hadn’t heard of Bruce Mau before, but I am always interested in design and design methods.
The gallery is essentially laid out to be controversial, to challenge one’s status quo thinking. In a video, Mau says, “practically everything that we do is being designed or redesigned; if you think about the way that we live now our life from womb to tomb is a design experience. If we want a great life experience you have to design it.” Mau goes on to say his work is focused on allowing people who aren’t designers to have access to the power of design, in their life, their work, in their business. Giving people the tools to design their future in a highly positive way.
Almost at the door of the gallery is a huge exhibit detailing his “incomplete manifesto for growth”. And the manifesto principles look like a superset of the Agile development manifesto, but writ large, with vastly greater ambition. First there are 43 principles. What! I say to myself, how can that many principles be useful? But of course once you start reading you are hooked. The Agile principles are embedded, but there’s much more. Let me give you a taster:
1. Allow events to change you. You have to be willing to grow. Growth is different from something that happens to you. You produce it.
5. Go deep. The deeper you go the more likely you will discover something of value.
8. Drift. Allow yourself to wander aimlessly. Explore adjacencies. Lack judgment. Postpone criticism.
9. Begin anywhere. John Cage tells us that not knowing where to begin is a common form of paralysis. His advice: begin anywhere.
13. Slow down. Desynchronize from standard time frames and surprising opportunities may present themselves.
16. Collaborate. The space between people working together is filled with conflict, friction, strife, exhilaration, delight, and vast creative potential.
20. Be careful to take risks. Time is genetic. Today is the child of yesterday and the parent of tomorrow. The work you produce today will create your future.
22. Make your own tools. Hybridize your tools in order to build unique things. Even simple tools that are your own can yield entirely new avenues of exploration. Remember, tools amplify our capacities, so even a small tool can make a big difference.
29. Think with your mind. Forget technology. Creativity is not device–dependent.
31. Don’t borrow money. Once again, Frank Gehry’s advice. By maintaining financial control, we maintain creative control. It’s not exactly rocket science, but it’s surprising how hard it is to maintain this discipline, and how many have failed.
39. Coffee breaks, cab rides, green rooms. Real growth often happens outside of where we intend it to, in the interstitial spaces—what Dr. Seuss calls “the waiting place.”
41. Laugh. People visiting the studio often comment on how much we laugh. Since I’ve become aware of this, I use it as a barometer of how comfortably we are expressing ourselves.
These are just a sample. You get the idea. This is Agile for the real world. For those people that are stuck in the zone of religious adherence to Agile development methods this may be anathema. But it’s a wakeup call. Invent your own.
The complete list and much more . . .
Work on What You Love: Bruce Mau Rethinking Design
November 21, 2015 – April 3, 2016
AFTERWORD: I wonder to what extent these principles map to a variety of design disciplines? In fact surely all design disciplines are creative processes. Would this include musical composition? I see no reason why not.
Link: https://go.forrester.com/blogs/17-07-09-devops_from_unicorns_to_mainstream/
Every day I hear more about the pressure I&O organizations are under to accelerate the delivery of applications and services and the pressure it is placing on the existing resources. As organizations transition, DevOps, formally the purview of unicorns, is now transitioning to mainstream. DevOps, which started as a grassroots approach by development organizations who […]
Link: http://feedproxy.google.com/~r/TheEnterpriseArchitect/~3/cE4hBLsOUtg/
The key to scaling a software engineering organization is stable teams. A while ago I wrote about the need to focus on stable, autonomous teams. Teams with members that trust each other and thereby become more than the sum of their parts. That is, in the end, the ultimate dream of a software development manager: to create cross-functional, self-organizing, high-performance teams. Teams self-organize around a compelling mission and have a big sense of ownership.
The consequence of this is that a lot of focus is on the team instead of the individual members. It is often said in the context of “agile” that you have to forget titles (everyone is “team member”) and forget heroic actions. This is easier said than done. It requires a cultural change and even then you will probably notice huge differences in the performance of your teams.
Not so surprisingly, just putting some random people together and calling it a team is apparently not the solution to everything. Peter Drucker already said it: “Only three things happen naturally in organizations: friction, confusion, and underperformance. Everything else requires leadership.”
So, what does “leadership” mean in the context of agile teams? How do we build strong, high-performing teams?
Before we can try to answer these questions we need to explore the factors that distinguish great teams from mediocre teams. Sam Walker actually did this for sports teams in his book “The Captain Class“ (I highly recommend to read it, it’s fun and thought-provoking).
In this book, he sets out to answer one of the most hotly debated questions in sports: what are the greatest teams of all time? He devised a formula, then applied it to thousands of teams from leagues all over the world, from the NBA to the English Premier League to Olympic field hockey. When he was done, he had a list of the sixteen most dominant teams in history. At that point, he became obsessed with another, more complicated question: What did these freak teams have in common?
You would think it depends on the star players, the ones that all fans know and that are basically the public face(s) of the team. Or the coaches, they are often celebrated as the strategic masterminds that brought the big successes. However, as Walker dug into the stories of these freak teams, a pattern emerged: each team had the same type of captain. There is a clear pattern in the dominant periods of these freak teams: they started when a certain person become captain of the team and ended when this person left. Or to say it in other words: there is a strong correlation between the captain and the performance of the teams, stronger than with other factors like the coach, overall talent, and money.
Apparently, what we need in order to build a strong team is a strong leader. But a strong leader might be someone with a different skillset than you expect.
When we think about a strong leader we have a certain type of person in mind. Brave, steadfast, charismatic, inspirational, talented, the public face of the team. This leader gives speeches to motivate the team just before they need to face their biggest challenges. Speeches that are memorable and inspirational.
However, if you compare the captains of the teams discussed in “The Captain Class” they were quite different. They lacked superstar talent, they weren’t fond of the spotlight, they didn’t lead in the traditional sense, and they even did potentially divisive things. They weren’t the usual suspects, so to say.
These captains did resemble each other, though. Here are the seven things they shared in common (all discussed in detail in “The Captain Class”):
These are the seven traits that Sam Walker identified as the commonalities among the captains of the top performing sports teams in history. What can we learn from this in the context of software development?
There surely is a trend nowadays to reduce hierarchy by not appointing team leaders. A team only has members, sometimes with different roles, but no explicit leader. In addition, when you research the concept of “leadership” you will be bombarded with all the positive traits that leaders should aspire. This sets an unreachable high bar.
What I like about “The Captain Class” is that it revives the importance of team leadership. It also shows that extremely successful captains (team leads) were not abundantly talented or charismatic. It shows that great team leadership is actually in reach and what to focus on: the seven traits as described above.
When I translate this into the context of software engineering and compare it with my own experience over the last years, I’m getting to these conclusions:
What is your take on leading agile teams? How do you scale your engineering organization? Please share!
The post The case for strong leadership in agile teams appeared first on The Enterprise Architect.
Link: https://go.forrester.com/blogs/the-forrester-wave-continuous-testing-service-providers-q3-2017/
Digital disruptors and customer-obsessed organizations are improving customer experience (CX) by shortening their software delivery cycles, delivering features in smaller increments, and scaling their existing Agile processes with DevOps. Traditional testing services don’t cut it for these organisations. In fact in my recent Continuous Testing Services Providers, Q3 2017 wave research, 38 business leaders representing the top […]
I am seeing more and more inquiries focused on driving business transformation where the transformation depends on software and business technology. ING is a model for digital transformation, and Ralph Hamers, CEO, has publicly reinforced the bank’s transformation. Hamers stated “We have to recognize that technology is what Banks do”[i]. Every business today must focus […]
Link: https://blogs.gartner.com/james-mcgovern/2017/04/05/leanea-part-one/
Prior to joining Gartner, I was an Enterprise Architect practitioner for a Fortune 100 enterprise that embraced Lean Thinking. The principles of driving both business-outcome driven EA and holistic technology implementations across value streams was something I got really good at. I found joy in enterprise programs that came with big hairy audacious goals (BHAG) for this provided me with a quantifiable target I could orient my own thinking around as well as help extended team members truly understand what we were driving towards.
I have come to appreciate that various aspects of architecture work don’t just happen in the Enterprise Architecture team itself but rather in different teams, so I had to continually check-and-adjust my approach based on the increasingly virtual nature of work.
The Lean concept of Gemba (Japanese for “go and see”) became part of my DNA because I wanted to operate on facts, not assumptions. For one month, I decided to track the amount of time I spent at my own desk and made a personal goal to spend less. In November, I spent a whole six hours at my office (large cubicle). Wonder if even having an office nowadays is considered waste? Anyway, I had the opportunity to not just interact with the “business” but also had conversations with the customers of the “business” that opened my eyes to new possibilities that wouldn’t have appeared on my radar if I just sat at my desk reviewing “requirements”.
If you are an Enterprise Architect in a shop that is embracing Lean Thinking, may I suggest that you will be well served by maintaining personal connections to each value stream under your stewardship? For me, go and see also applied to development teams for in order to be certain that I was championing better business outcomes, I wanted to know that “as-designed” was the same as “as-built”. From an organization chart perspective, I was senior to pretty much every developer, but that never stopped me from going to their desk and engaging in a conversation such that I could understand what aspects of our goals were understood vs getting lost along with a healthy dose of Agile thinking where I wanted to see “working software”
A funny thing happened. Developers and testers grew both their trust me as well as the strategy in which I was the keeper of the flame. Showing to business stakeholders and IT teams that the Enterprise Architect knows their current challenges and context is powerful. The Gemba has more power than it is given credit for. I am hopeful to hear success stories of other Enterprise Architects following the same path.
The post Enterprise Architecture and Lean Thinking: Part One appeared first on James McGovern.
Lourens Riemens, an Enterprise Architect with the Netherlands Tax & Customs Administration, will be speaking at The Open Group Amsterdam event about how the agency has used ArchiMate®, an Open Group standard, for greater consistency, overview and insight. We spoke to him in advance of the conference to get a preview.
Link: https://blog.opengroup.org/2017/11/02/the-open-group-amsterdam-2017-event-highlights/
The rapid pace of technology innovation in today’s digital economy means that businesses require a level of agility and responsiveness that cannot be delivered by conventional business strategies and operating models.
This event focused on how Enterprise Architecture and the use of standards from The Open Group, such as TOGAF®, ArchiMate® and IT4IT™ (for managing the business of IT), are empowering companies to build better systems by architecting for digital business strategies.
Topics included: EA and Business Transformation; EA in Government; EA in Healthcare; Internet of Things (IoT) and Smart Cities; Risk Management and Cybersecurity; Process Automation; and IT Management.
