Skip to content

Feed aggregator

SAFe 4.0 in 5 minutes video

Agile Product Owner - Mon, 05/16/2016 - 20:51

Hi All,

Introducing SAFe to people that are unfamiliar with it can sometimes seem like a daunting task. People build really big systems with SAFe, so SAFe is not a trivial framework. As part of our efforts to make SAFe more accessible (for one such example, see the blog post on Essential SAFe), we’ve just released a short, informal five-minute video, which gives a brief overview of SAFe and how it works. You can find it here.

SPCs have used previous versions of the video in their Leading SAFe or SAFe for Teams class. It’s also a handy, short introduction for anyone new to SAFe. It can also be used to help garner the interest needed to attract people to a session based on SAFe Foundations, SAFe in 8 Pictures, or even to a Leading SAFe class.

We hope you find it useful,

-Inbar Oren
SAFe Fellow

Categories: Blogs

The Simple Leader!

Evolving Excellence - Mon, 05/16/2016 - 18:21

 PRS0000030_00044]A few years ago I starting playing around with a book concept that described several personal and professional leadership methods and habits I had developed over my three decade career. I collected ideas, supporting information, and would occasionally – often on long plane trips – take a stab at writing a section or two. I even put those up on LeanPub for folks to review and comment.

For many reasons I never made much headway. There was always something a bit more pressing, or seemingly more manageable, than tackling that behemoth of a project. I enjoy writing, and I felt I had something important to share, but it was never THE priority. In the meantime the project occupied valuable space in my brain.  As I get older I’m realizing just how valuable that space is.

Then, last fall at the Lean Accounting Summit, I was approached by an attendee who introduced himself and immediately asked when I was going to finish the book. He knew from my blog and LeanPub that I had been working on it, and he said the story so far had really helped him improve his own leadership style. I decided it was time to either put up or shut up (the polite version of the phrase), and one way or another resolve the project and get it out of my head.

I put up. I sequestered myself on a tiny island for two weeks in December and finished the writing. That draft went through several rounds of brutal editing by a professional copy editor, then text and graphic design. Several colleagues provided very valuable reviews, and Matthew May was kind enough to write a foreword. Todd Clarke did a great “visual one pager” summary.

A week ago I received the final proof, and yesterday the book went live on Amazon. Kindle and iBook versions are just a few days away.

The Simple Leader: Personal and Professional Leadership at the Nexus of Lean and Zen.

Receiving that final proof felt incredibly good.  It is done and I’m very happy with how it turned out. I’m sure I’ll think of improvements over time, but for now the project is complete, and it is no longer consuming space in my head.

The book is organized into eight parts, each with a different purpose:

  1. Fundamentals – A quick history lesson and exploration of the basics of Lean and Zen.
  2. Reconnect – Before doing anything, a leader has to be in touch with her or his inner self.
  3. Create – Methods to improve personal productivity to prepare for the work that is coming.
  4. Lead – How to engage and lead your team as you begin the improvement journey.
  5. Clarify – Clarifying what you and your organization are about, defining the current state and the desired future state, and creating a plan.
  6. Simplify – Using your new plan, you can take the first step and simplify your operation within the context of that plan.
  7. Improve – Methods to identify and execute improvement projects within the context of your plan.
  8. Grow – Within ongoing improvement projects in place, it is time to stretch yourself and your organization even further.

I’ve been humbled by some of the initial reviews:

I have long felt that Lean thinking and mindfulness are the two most important breakthroughs in recent years to help us sort out increasingly chaotic lives. Practicing Lean thinking is a clear path to professional success in hypercompetitive markets just as practicing mindfulness is the way to wellbeing in adverse conditions.  It also turns out that both build on each other, which is what Kevin masterfully demonstrates in this frank, well-written and deeply insightful account of his own journey. The Simple Leader is simply a fantastic read!
Michael Ballé, author of Lead With Respect: A Novel of Lean Practice

Leadership is at the core of any organization, and transforming leadership mindsets and practices is at the core of Lean management. Meyer is a rare author who’s not only studied Lean deeply but has also served as CEO. The Simple Leader is chock full of essential leadership practices that are key to organizational transformation and outstanding business performance alike.
Karen Martin, author of The Outstanding Organization: Generate Business Results by Eliminating Chaos and Building the Foundation for Everyday Excellence

If you’re thinking, “Not another book on leadership,” then you’re in luck. This is not the same old vacuous pablum that so many consultants peddle, or the same sophomoric insights that Zen fanboys wax lyrical over. Kevin’s experience as a business CEO, a student of Lean, and a practitioner of Zen combine to produce a uniquely insightful, wonderfully practical guide to management that will be useful to anyone seeking to be a better leader. I defy anyone to read this book and not learn something immediately useful, applicable, and valuable.
Daniel Markovitz, author of Building the Fit Organization: Six Core Principles for Making Your Company Stronger, Faster, and More Competitive

I’ve always been impressed by Kevin’s dedication to simplicity. This book collects his insights from a lifetime of experiences, travel, reading, work and reflection into a simple and practical book. Open up the table of contents and place your finger down on any topic, and I guarantee that you will find practical hints and insights in this book to help you improve. Take a moment to invest in yourself by reading and reflecting on how to reduce complexity in your life and work.
Jon Miller,author of Creating a Kaizen Culture: Align the Organization, Achieve Breakthrough Results, and Sustain the Gains
Lean and Agile thinking are founded in a deep ‘Respect for People’, experiential learning, and a realization that continuous improvement and innovation come from direct observation at the Gemba. In our increasingly complex, distracted and over stimulated world, presence and mindfulness, captured in the Zen instruction to ‘Pay Attention!’, are increasingly relevant. This book may not only change how you lead, but also how you live.
Steve Bell, author of Run Grow Transform: Integrating Business and Lean IT

One might say then that Simple, Leader, Lean, and Zen are inherently conflicted, at odds with one another, and that reconciling them would entail a rather Herculean act of creativity. But creativity is the act of bringing something new into existence, the defining quality of which entails connections between seemingly disparate ideas. This is the beauty of The Simple Leader. This is power of the Lean-Zen nexus.
Matthew May, author of Winning the Brain Game: Fixing the 7 Fatal Flaws of Thinking

Effective personal leadership, requiring conscious individual reflection, is a critical foundation for effective professional leadership. Building on his deep hands-on experience with core Lean and Zen concepts, principles and practices, Kevin Meyer provides the reader with concrete advice and examples necessary to become that outstanding leader. In The Simple Leader Kevin demonstrates how each of us can gain leadership clarity by reducing leadership strategy and processes down to a handful of important truths.  The Simple Leader is a short read that delivers with impact. Read this book.
Adam Zak, co-author of Simple Excellence: Organizing and Aligning the Management Team in a Lean Transformation

The simple leader is not simple at all! The simple leader is the one who has tamed complexity with the notion that simplicity is true elegance.  The irony is that the more successful we all become, the more we are enveloped by complexity and reject the intelligence of simplicity. The idea that Kevin could succeed in the business world and understand that success is rooted in simplicity is profound. The Simple Leader is a fantastic story of how Kevin has done this and I was taken with his honesty and brilliance.
Paul Akers, author of Lean Health: Aging in Reverse

Thanks to all of you who have supported me on this journey!

Categories: Blogs

New Practical Product Ownership Workshop Dates

Johanna Rothman - Mon, 05/16/2016 - 17:56

I just posted the dates for the next Practical Product Ownership workshop: Deliver What Your Customers Need. It starts Aug 23, 2016.

You need this workshop if:

  • You are having trouble doing everything in your PO role, you might be trying to do too much. See Product Manager, Product Owner, Business Analyst?
  • You are having trouble deciding how to organize your backlog, roadmap, and everything.
  • How to value the items you do organize. We discuss Cost of Delay and seven other possibilities to rank the items.
  • How to help people articulate the problems they want the team to solve, not the solutions.
  • And much, much more.

We meet twice a week for six weeks. Our first meeting is a 90-minute teaching call, where I teach and you ask questions. We meet later that week for a 60-minute coaching call, where you bring your problems, concerns, and challenges.

I estimate you will have about 60-90 minutes of homework every week. Any other questions? Email me.

Categories: Blogs

Henry Ford and Design Thinking

By LibertyGroup25 (Own work)
Henry Ford pioneered many of the ideas that are now commonplace in business, including ideas used in Design Thinking. He has been quoted as saying "If you ask people what they want, it would be a faster horse." This hits on the design thinking principle of divergence. You need to understand what problem you are solving before coming up with a solution. Henry Ford wasn't solving a problem around horses, he was solving a transportation problem.

I was in a design thinking workshop and we did an exercise where first we were asked to draw a door bell. Then we were given a problem in a different framing, we were asked to draw a way to know if someone was at the door. The second set of drawings were much different. A doorbell would have worked, but by reframing the question, many other solutions came out.

Another Henry Ford quote is "you can have any color, as long as it's black." On the surface, this might not sound very customer friendly, However, this response was due to the solution to another problem. When he was developing the production line for the Model T, he was challenged in the painting step. He found all paint colors took to long to dry, except black. By only offering black, he was actually fixing a bottle knock in his process...applying the theory of constraints as it were.

Next time you're working on a solution to a problem, spend a few minutes and think about the framing of the question. Can you change the question in order to expand you possible solutions?
Categories: Blogs

Custom Errors w/ Clean Stack Traces in Node.js

Derick Bailey - new ThoughtStream - Mon, 05/16/2016 - 13:30

Some recent discussion in the WatchMeCode slack spawned a bit of research into creating custom errors through factory methods, while keeping the stack trace for those errors clean, in Node.js

After a bit of digging, I found a good solution using Node’s Error.captureStackTrace method, and recorded a quick screencast to highlight it’s use. 

The Screencast

The Sample Code

If you’d like to run the sample code that I showed in this screencast, you can grab it from this gist

Additional Resources

And if you would like to read up on errors further, check out these additional resources:

Categories: Blogs

Workshop Valuable Agile Retrospectives in Utrecht

Ben Linders - Mon, 05/16/2016 - 12:20

Op 21 juni geef ik de workshop Valuable Agile Retrospectives in Utrecht. In deze succesvolle workshop leer je de waarom, wat en hoe van retrospectives en oefen je in teams met diverse manieren om retrospectives uit te voeren. Continue reading →

The post Workshop Valuable Agile Retrospectives in Utrecht appeared first on Ben Linders.

Categories: Blogs

Links for 2016-05-15 []

Zachariah Young - Mon, 05/16/2016 - 09:00
Categories: Blogs

The Power of Agile is in your Customers and Employees

I’m Agile, you’re Agile, everyone is Agile.  Or folks think they are.  But are they really? If Agile is only a process to you, Agile will fail. If Agile is pretending certainty without validating with customers, then Agile will fail. If Agile is commanded from above with little ownership from the team, Agile will fail.  More importantly, not only Agile will fail, so will your business.  Agile is a move to a lean culture focusing on customers and what they find as value and focusing on employees who are the engine that can create that value.  Agile is effectively about creating a thriving business. 
I believe there are the two primary success factors in creating a thriving business: a culture where customers matter and employees matter. I’m not talking about the lip service that is prevalent today. In some cases, we see quite the opposite, where employees are disenfranchised and customers are rarely engaged. Instead, the goal is to have a culture and practices in place that truly gain the benefits of engaging with customers and employees. Through the customer and employee, a company draws their power within an agile culture and, I contend, within any thriving company. When you have a riveting focus on the customer and you believe that an engaged customer matters, then you have the basis for a relationship where you can truly understand what the customer wants. When you have a sharp focus on employees and provide them the space to make decisions and own their work, then you will begin to understand the value an engaged employee base can provide.
If the values are sincerely translated to organizational objectives and agile approaches are applied, then it can act as a differentiator between the success of your organization compared to the success of other organizations. Of course, every company likes to say that employees and customers matter, but are their objectives and actions really aligned with these values? Upon closer inspection, the values should translate into objectives focusing on customer engagement and employee engagement.
  • Customer engagement focuses on establishing meaningful and honest customer relationships with the goal of initiating continuous customer feedback to truly identify what is valuable to the customer. This includes establishing all of the activities involved in a Customer Feedback Vision.
  • Employee engagement focuses on empowering employees so they can self-organize into teams and can own and be a part of the decision-making process at their own level.  When employees have ownership, they have more passion in their work.  When they have more passion, they give 110%. 

Then we add the “secret ingredient” of applying a continuous and adaptive approach (a.k.a. agile culture, processes, methods, practices, and techniques). If done properly with the ability to adapt, this can lead to an increase in customer sales and an increase in team productivity. This finally leads to your incentive, which is an increase in company profits.  
Now is time to take a moment.  Are employees disenfranchised or fully engaged?  Are customers rarely engaged or is their feedback continuously engaged?  Is Agile just a trend that others should do or are you serious about Agile and the culture shift it requires?  Keep in mind, the combination of customer and employee engagement within an Agile context isn’t just a good idea, it is great for business.  
PS - to read more about the importance of customers and employees, consider reading Chapter 3 of the book entitled Being Agile.  
Categories: Blogs

SATURN 2016, San Diego - Sun, 05/15/2016 - 16:54

I first heard of SATURN via social media through Michael Keeling, an IBM employee who spoke at XP2009 many years ago. Sam Newman spoke last year about Microservices. Although the conference has a Call For Papers (CFP) each year, they also had a small number of invited speakers and Michael organised for me to go along to talk about Evolutionary Architecture.

SATURN is a conference organised by the SEI (Software Engineering Institute). SEI are probably most well known for CMM, although there is now another institute responsible for it. The conference has been running since 2005 and has a long history of focusing on architectural concerns.

Architecting the UnknownArchitecting the Unknown keynote by Grady Booch (@Grady_Booch) What I really liked about the conference

I believe that one of SATURN’s greatest strengths is a focus on architectural thinking, through the application of the latest tools. Unlike some other conferences, I felt like the programme tried to assemble a good collection of experience reports and presentations that emphasised the architectural principles, rather than focusing on the current tools.

Although this may be less popular for people wanting to learn how to use a specific tool, I feel this emphasis is much more valuable and the lessons longer lasting.

What I also really enjoyed about the conference was the relatively small size which was just over 200 participants from various parts of the world. Having a good location, and small size allowed for some better quality conversations both with other speakers and attendees. One good example of the conference facilitating this, was an office hours session for attendees to easily ask questions of speakers. I shared by office hours with Eoin Woods (author of Software Systems Architecture) and Grady Booch (IBM Fellow, One of the Three Amigos who were best known for developing the Unified Modeling Language).

SATURN 2016 Conference DinnerConference dinner at a baseball game for SATURN 2016

Another example to reinforce that was connecting with Len Bass (one of the authors of Software Architecture in Practice) at the conference dinner (at a baseball game).

Other observations

During the conference I spoke with many people carrying various Architect titles. Interestingly many came from many larger organisations and government agencies, which shouldn’t have been any surprise given the history of the conference. I remember meeting and speaking with one particular Enterprise Architect (EA), who seemed to be one of the most pragmatic EAs I’d met, who was trying at all costs to stop his board randomly signing large contracts with product vendors like Oracle and IBM without the proper diligence about understanding what they were actually building.

At the same time, I met a number of architects struggling to help their organisations see the value of architecture and the role of the architect.

My talk

I spoke after Booch’s initial keynote, “Architecting for the Unknown” which lead really well onto the topic I was speaking on, “Evolutionary Architecture“. I had a packed room as was a topic that resonated with people. At one point the conference organised brought more chairs into the room and there was still only standing room for the 90 minute talk! I had some great questions and conversations throughout and found out later that I won the award for the best conference talk in the “Architecture in Practice” category!

Evolutionary Architecture TalkSATURN Evolutionary Architecture talk audience

I’d definitely recommend attending SATURN if you’re interested in focused on building architectural thinking and an opportunity to connect with architects across the industry. The size is great for conversations, sharing experiences and with next year’s scheduled for Colorado will be really interesting too.

Final thanks

I’d like to thank the organising group calling out Michele Falce (Technical Event Coordinator), Bill Pollak (General Chair), Jørn Ølmheim and Amine Chigani (Technial Co-Chairs) who did a great job putting together a fantastic conference, John Klein for hosting Office Hours, and Michael Keeling for organising an invite for me.

Categories: Blogs

Pitch your product using the 3x3 framework

Xebia Blog - Sun, 05/15/2016 - 11:26
When pitching innovative product ideas, you only get between five and fifteen minutes of attention. To make those minutes count, you should be able to define your product vision in a simple but comprehensive way. For this, I’ve found this 3x3 framework technique useful. Not only is it a pretty good format for pitching your
Categories: Companies

SAFe as a Framework

NetObjectives - Sun, 05/15/2016 - 10:36
The Merriam-Webster dictionary defines a framework as "the basic structure of something: a set of ideas or facts that provide support for something." Clearly, SAFe is more than a framework; it also offers a set of practices and patterns to fill in the framework and this is how it is taught in the standard SAFe course. The advantage of this is that people understand the essence of SAFe faster....

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

Links for 2016-05-13 []

Zachariah Young - Sat, 05/14/2016 - 09:00
Categories: Blogs

How Integrating Zendesk with LeanKit Changed Customer Support

My name is Andy Hoover and I manage our Customer Support operations here at LeanKit. I spend...

The post How Integrating Zendesk with LeanKit Changed Customer Support appeared first on Blog | LeanKit.

Categories: Companies

Versnel je team met Scrumban!

Xebia Blog - Fri, 05/13/2016 - 14:01
Herken je dat ook? Teams die meer dan een half jaar aan het scrummen zijn en sprint commitments maar niet halen? Of maar geen stijgende 'velocity' laten zien? Blijven verbeteren zonder een echte verbetering te zien? Scrumban is het toepassen van de Kanban Methode in de context van scrum en geeft deze teams een weg
Categories: Companies

My Favorite Thing To Do With Code

Derick Bailey - new ThoughtStream - Fri, 05/13/2016 - 13:30

There are a lot of great aspects of software development, including writing code, solving problems, and generally working with cool technology and toys.

But of all the things that I do as a developer, there is 1 thing in particular that I absolutely love doing. And that one thing? It’s not solving problems, surprisingly (though this is probably a close 2nd).

Categories: Blogs

Monorepos for true CI

Xebia Blog - Thu, 05/12/2016 - 21:23
On the 15th and 16th of April CITCON Europe took place in Cluj-Napoca (Transylvania). CITCON is an open spaces conference. The agenda is made up by the people attending the conference. Because of this there are always a couple of nice takeaways. This year Ivan Moore (@ivanrmoore) made a claim that you can not do
Categories: Companies

Using Return on Team to Enhance Business Agility

BigVisible Solutions :: An Agile Company - Thu, 05/12/2016 - 19:00

At this year’s Global Scrum Gathering in Orlando, SolutionsIQ President John Rudd and I presented on the topic of Agile portfolio management. During our presentation, Andreas Schliep (long time Certified Scrum Trainer, Agilist, and hilariously dry-witted guy based in Germany) tweeted,

“Brent Barton and John Rudd gave the term business agility a useful meaning. Think portfolio.”

What is Business Agility?

Prior to the presentation, Andreas told me how concerned he was with the term “business agility” because it lacks meaning and can water down a company’s ability to derive the real benefits from being “Agile”. Luckily for Andreas and many people attending our session who were uncertain about what exactly business agility is, thinking about it from a portfolio perspective provided a pragmatic way for business to support a modern organization. Now I’d like to share here what we shared to participants that day.

Simply put, business agility means leveraging iterative delivery capability and actively managing organizational investments. The bottom line is that, if we do not align our portfolio practices to leverage what Agile has to offer, we miss out on opportunities to maximize returns and adjust plans.

The rest of this blog is dedicated to “thinking portfolio” and one of its most important components: Return on Team.

What is Return on Team?

Return on Team aligns today’s needs for planning and budgeting.  It is a better and simpler way to manage a portfolio.  In many ways,  small (<10 people), dedicated, persistent, cross-functional, empowered, self-organizing teams are at the core of Agile.  This structure is best for knowledge workers who solve today’s complex problems like software solutions.  Rather than dissolving teams (in particular high-performance teams) and incurring the unnecessary overhead of reintegrating individuals, we can think of these teams as assets.  Further, establish these dedicated and persistent teams as enduring corporate assets.  Then like tracking return on an asset, we plan and track Return on Team.

Consider an airplane. Notice that in the previous sentence, I said “an airplane” indicating that it is a concise unit by itself. But you could, as engineers may, consider the entire vessel a collection of many integrated parts that operate in concert to produce the value that airline customers seek (i.e., flying from point A to point B). It seems ridiculous to think about a single airplane as a bunch of constituent parts–and yet this is precisely how we think about individual team members on a team. The team is an airplane: the individual parts (team members) collaborate and coordinate to deliver the value that end-users seek, whether that’s software or something else. When you have a high-performing team, the last thing you want is to break them up just when they’ve achieved velocity–probably for the same reason you wouldn’t dismantle an airplane midflight. But just like you can move an airplane from one hangar to another (even when it isn’t carrying passengers), you can reassign a team from one initiative to another one. Your teams are enduring corporate assets, like a fleet of airplanes. Once they’ve hit their stride and produced consistent value quickly, you can actually plan and track accordingly. That is the combined power of Return on Team and active (Agile) portfolio management.

Return on Team-01

The team is an airplane: the individual parts (team members) collaborate and coordinate to deliver the value that end-users seek.

Return on Team allows planners to match supply (team capacity) to demand in a data-driven manner.  This simplifies the process by an order of magnitude and prevents us from accidentally pulling people off one team only to re-form another and incur transition costs. Also, we have better data as a result.  When a system does not change, history is the best indicator of future performance.  By keeping teams persistent, we can use historical data to plan more realistically.

How Do You Measure Return on Team?

There are two ways to measure Return on Team: trend and performance against plan.  Since persistent and dedicated teams focus on a common delivery stream, relative contribution to a corporate endeavor is easy to measure.  Also, teams tend to get better at estimating over time. Costs are more stable, so they can be calculated simply.  For example: one team costs $25,000 per week.  Thus, if a piece of work is budgeted at $300,000, the team has 12 weeks to finish the work before the budget is exhausted.  If it is a stable team, we can use previous trends to calibrate likelihood of a good outcome very early.  Regardless how an organization calculates benefits (and expected benefits), the denominator of the basic benefit/cost ratio is very simple and maps into team’s work without friction. The result is greater predictability and thus reduced risk, with the ability to move away from investments that are not showing benefit.

Finally, most of the work teams do is based on investments much longer term than a year, except when the organization is in search of new potential long term investments.  Thus, in order to support short term business commitments against long-term investments, we need to become good at developing short-term initiatives (often about a quarter in length) so we can course correct without as much gnashing of teeth.  These short term-initiatives can be estimated in comparable team units which we call a team iteration.  Now, we have units of supply that we can match to demand with short-term outcomes derived from long-term commitments.  From this, we can base our decisions from the perspective of Return on Team.


In review, persistent and dedicated teams, as corporate enduring assets, delivering increments of customer value every iteration cycle with a predictability that portfolio managers can use to plan short-term initiatives that drive toward long-term investments–that is the ultimate goal of business agility. The Agile business can plan with a greater level of confidence and predictability and reduced level of risk.


To learn more about Return on Team and business agility, check out Brent’s webinar “Agile Portfolio Management: Adapting to Changing Priorities”!

Watch Now

The post Using Return on Team to Enhance Business Agility appeared first on SolutionsIQ.

Categories: Companies

Entities aren’t resources, resources aren’t representations

Jimmy Bogard - Thu, 05/12/2016 - 18:29

One of the easy mistakes in building a REST API is trying to take your rows out of the database and expose them directly as JSON. Such technology exists, where you can directly expose stored procedures as SOAP web services, or protocols like OData.  You can also just expose your entities directly as JSON through a web service, but you’re missing out on some big distinctions of resources and representations.

So first, what is a resource? That’s actually quite easy – a resource is anything with a URL. The converse is not true, a URL is not a resource, mainly because the URL is the Uniform Resource Locator. If you can locate a resource, then it exists. And Fielding was pleased.

The representation is a bit different – it describes the current state of the resource (when requested).

So what does this have to do with entities? Well, nothing. There is no relationship between entities and resources. And that’s a good thing, it’s exactly how the web works.

When you navigate to a web page, an online retailer, and look at a list of products, what is the resource? From the client’s perspective, we don’t know. We have no idea of the implementation details of the resource, other than a way to locate it and request a representation. Again, Fielding was pleased, as this decoupled us from the implementation details of the resource.

So where does this leave us when building APIs?

A decoupled API

In APIs that serve the client according to their needs, the resource often includes details from many different data sources, combined together to build a representation to the end user. A REST API builds all this together:


In hypermedia APIs I build, the resource state combines multiple entities together from one or more data sources into the state of the resource. This plus links, forms a queries makes a “resource”, though it’s still a bit more abstract than that. Finally I build out the representation, perhaps JSON API, HAL, Siren etc.

If I made my entities equivalent to resources, I’m likely forcing clients to make many round trips to all the entities they need, but even more, I’m directly exposing the implementation details of my service to the world. Perhaps I’m removing some fields here and there, but in reality this is only one step above handing clients a connection string to my database. Sure, it’s easy and convenient to expose entities directly as resources and representations, but there’s some serious coupling that comes with that choice that you must accept.

In my experience, if I approach the API design strictly from the client perspective, on what they’re trying to achieve and why, it’s actually quite rare that I arrive at an API design that is simply database CRUD exposed as HTTP. And Fielding was pleased, as this design most closely matches the everyday use of the web. Makes sense. That’s what REST is about – a set of architectural constraints describing basically, the web.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Categories: Blogs

Knowledge Sharing

SpiraTeam is a agile application lifecycle management (ALM) system designed specifically for methodologies such as scrum, XP and Kanban.