The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win

First of all, I loved the book! With The Phoenix Project, Gene Kim, Kevin Behr, and George Spafford has written one of the most thought-provoking IT books I've read in recent years. The Phoenix Project is actually a novelization of DevOps principles rather than a strict how-to book on transforming IT Operations. It is written in the tradition of IT Novels such as the Stealing The Network series, which I read voraciously when I was learning about Information Security. I find the idea of using the genre of fiction to teach IT theory to be extremely effective, especially the concepts of DevOps, which are foreign to so many who are in the "traditional" IT space. The Phoenix Project provides a vivid use case that describes the dysfunctional relationship which exists, not only between traditional IT and the Lines of Business, but between different groups within IT itself. But not only does the book describe the problem, it offer a path to follow in order to transform IT into a true partner to the Business. The protagonist in The Phoenix Project is Bill Palmer, newly promoted to VP of IT Operations for Parts Unlimited, a leading automotive parts manufacturer and retailer. The problem is that Palmer has been promoted because his managers were fired due to the failures of the IT department, particularly in completing a software initiative, called The Phoenix Project. This Phoenix Project is a software suite, developed in-house, designed to integrate manufacturing and retail while allowing Parts Unlimited to be more agile and nimble in accommodating to changes in market conditions. The project is intended to save the company, which has missed earning consistently and has fallen behind its main competitor; unfortunately, the project is millions of dollars over-budget and years late in delivery. Palmer is thrown on to the proverbial sinking ship and quickly caught up in one emergency after another and soon realizes that unless something quickly changes, The Phoenix Project is doomed to failure and along with it, Parts Unlimited. However, Palmer finds himself ill-equipped to understand and to implement the necessary changes to right the ship, especially when there is so much distrust and infighting within the IT organization and with the Lines of Business. Then Palmer meets the enigmatic Erik Reid, a potential board member with some very unusual ideas for how to run IT Operations. Palmer is understandably skeptical but is soon drawn in as Reid takes him down the rabbit hole; through a series of encounters and events, Reid enlightens Palmer as to what is the true mission of IT and what must be done to make IT work as a partner to the Business. The truths that are discovered not only change Palmer but the entire culture of IT at Parts Unlimited. I had two different reactions as I was reading The Phoenix Project. The first half of the book often made me reflexively reach for the Maalox as I found myself standing in Palmer's shoes, reliving outages caused by buggy code and miscommunication between IT departments. The second half of the book reads like the script from The Karate Kid, as we see Erik Reid, Aka. Mr. Miyagi, guide Bill Palmer, Aka. young Daniel, down the path to enlightenment about not only the methodology of DevOps but the cultural shift that is required for change. Sometimes the lessons involve seeing tasks that seem to have little value to sound IT Operations, but Reid is able to masterfully walk Palmer through the process until he sees the proper connections between Manufacturing Plant operations and IT Operations. That relationship between Manufacturing Plants and IT was, for me, the key insight provided by the book. As Erik Reid succinctly states to Bill Palmer, "If you think IT Operations has nothing to learn from Plant Operations, you're wrong. Dead wrong. Your job as VP of IT Operations is to ensure the fast, predictable, and uninterrupted flow of planned work that delivers value to the business while minimizing the impact and disruption of unplanned work, so you can provide stable, predictable, and secure IT service." This is one of the best definition of IT Operations and also one of the most insightful statements on resource management that I've read to date. After all, what can be more basic to resource management, rather it be a data center, software development team, Cloud, or people, than ensuring they deliver value through the completion of planned work? Yet I would argue that because this is not the ultimate goal of many IT shops, they are easily sidetracked by the urgent and prevented from doing what is important. The rest of the book shows how Palmer, with help from Reid, is able to inculcate a new culture in the IT department at Parts Unlimited so they can focus on the mission of saving the company by enabling the business of the company. Along the way, they learn about the four categories of work (business projects, internal IT projects, changes, and unplanned work), the Three ways, and the importance of Kanban. Each new discovery by Palmer and team is a call to action for IT departments that know they cannot maintain the status quo and must transform themselves to meet the demands of the current business environment. I look forward to learning more and applying the principles from books such as the Phoenix Project. Now if only I could find a portable version of a Kanban Board!

I had the pleasure of meeting Gene Kim in October of 2011 at the Security B-Sides conference in Portland, OR. He had just presented on the concept for his novel, and I was immediately intrigued. It seemed like he intended to bring the concept of the business parable to IT management. I joked it looked like a Who Moved My Cheese? for the ITIL crowd. In speaking with Gene following his presentation, I thanked him in person for The Visible Ops Handbook: Implementing ITIL in 4 Practical and Auditable Steps (which I maintain is still the best $20 I ever spent). Through our conversation, he flagged me as the type of "boundary spanner" who would benefit from a more thorough reading of his new effort, and he nailed that assessment. I didn't want to put it down. The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win reads like a techo-thriller. I found it very engaging and definitely wanted to read the whole thing all in one sprint. I hadn't found myself that thoroughly engrossed in a read in quite some time. The cast is spot-on. Each is clearly meant to represent a specific organizational perspective or archetype. If you aren't one of these characters, you at least know someone who is. A few may seem a little exaggerated or caricatured, but that is more from a sense of literary license and less in any manner to offend. The roles are readily identifiable and it is easy to see oneself as any member of the cast. If this causes the reader any discomfort, one should perhaps take the hint. As I joined Bill Palmer, the story's main protagonist, on his odyssey as he deals with "late projects, chronic outages, massive audit findings and the imminent threat of outsourcing" and - having lived that adventure myself - I thought, "Been there. Done that." It is well known that projects, and corresponding confidence in IT, fail in predictable and repeatable ways. So, it is both disheartening and reassuring to see us doing things so perfectly wrong. Even more important is the illumination of a clear path out of that death spiral of angst and despair. Also of considerable use is the extensive bibliography of business literature from which Gene & co. have drawn. The reader is introduced to key concepts, from the Theory of Constraints outlined in Eli Goldratt's parable, The Goal: A Process of Ongoing Improvement , to the agile management techniques of David J. Anderson's Kanban and the leadership and team-building dynamics found in Patrick Lencioni's The Five Dysfunctions of a Team: A Leadership Fable without being hit over the head. The story informs, educates and provides a jumping-off point for those seeking additional knowledge in the fields of Lean IT and Agile Management. I believe The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win is already sold to my colleagues working in or managing IT operations. It will also be of interest to those IT professionals who are inclined to think outside of their silos and concern themselves with bigger picture issues relevant to the entire business. I see this becoming mandatory reading for executive staff and other enterprise stakeholders being enabled or constrained by their own IT processes. I will certainly attempt to influence that outcome in my own organization.

I have to admit something, I love case studies. When a software development book starts throwing out "examples" of the methodologies being discussed, I tend to get interested in the story. I start paying closer attention. If they're well-written, I get very interested. Generally, I find myself wanting more. Naturally, I don't get this - the book is a dry technical reference on software development practices and not a novel. The fiction interspersed within is meant to keep you interested. The Phoenix Project takes this idea to the somewhat strange conclusion. Instead of being an exploration of IT topics with fiction within it, this is a piece of fiction that is an exploration of IT topics. A particular IT topic, in this case - lean development and DevOps. For those not in the know - lean software development is an evolution of agile software development that attempts to take lessons learned from the factory line (especially Toyota and just-in-time management) and apply them to IT and development. Its been around a whilso; I recall attending a session at a conference about it at least five or seven years ago. DevOps is a much more recent concept that, I think, emphasizes a focus on all pieces of an application - not just the code, but its exeuting environment, its network, its process for being changed. Its a really new concept, and one st ill being explored (note that "The Visible Ops Handbook" is not actually a book, at this point). The book follows the "adventures" of Bill, a newly promoted head of IT for an ailing automotive parts/retail corporation. The company's IT department has a history of failing to meeting obligations and having a revolving door management. This is particularly problematic given that it is also responsible for delivering "Project Phoenix", a massive undertaking to revolutionize the company. It is not going well, and it is made clear to Bill that delivering Phoenix is vital to the future of his career. Bill himself seems like a nice guy, and is definitely the "reluctant hero" of this tale; he had no particular interest in advancing in his career and had to be cajoled by the CEO of the company. He quickly regrets this - the IT organization is an underfunded disaster, with failing infrastructure, absolutely no process or change management, and a single employee (Brent) who knows everything about everything. Bill's first day is spent running into a crisis involving the company's payroll, caused by the company's over-zealous head of IT security and leaving the company unable to print paychecks. It does not get better; Phoenix is quickly and clearly failing to meet a deadline pushed by a politicing SVP, whom has the power to push the CEO to demand its release on the unreasonable schedule of one week. No one working in the IT field will be surprised when this deadline proves a disaster, though in this case one of rather excessive scope. I will say at this point that it is clear the authors have been in one or more combinations of these disasters before - they write them vividly enough that I think anyone who has worked for a large IT organization will find themselves sympathizing with their plight and remembering past IT disasters of their own. Bill is mentored in his "quest" by Erik. A quirky potential board member with a history in the technology industry. Erik completely serves as the sagely master in this novel. Most of his lessons take place at a local factory, where he illustrates his points about the four kinds of work and how to deal with constraints and how to move work through the system. His quirky personality works extremely well - picturing him as the Yoda of the novel wouldn't be entirely far off. The book winds down to its conclusion through very interesting portrayals of corporate betrayals, triumphs, and even a character whom entirely changes their conception of their job and life. The end is, inevitably, triumphant - this probably wouldn't be an effective illustration of the principles the author wants to get across otherwise. As a piece of fiction, I'm a fan of this novel. It manages to make a dramatic, interesting story about a bunch of employees in a corporation learning about a new IT methodology. It, mostly, avoids stereotypes - the characters are well-defined and have actual motivations. Even the aforementioned Brent is presented reasonably, as a helpful person who has simply been around forever. He's a problem, but more in the way his job has developed than any particular maliciousness. The weakest characters here are probably John, the head of IT security, and Sarah, the villain of the piece. I get the impression that the authors have no particular respect for the way IT security runs at most orgs, and Sarah is mostly here to be a pushy, political executive. It works, for the story, mostly because the actual villain is the IT process - Sarah is simply there show the failings and stomp on them until they break. The other flaw is that the characters, especially Erik, are prone to exposition - this is probably unavoidable given the goals of the novel. In terms of this book's value as a work illustrating a new IT process, this is more mixed. They definitely explain all the points; I can't say I don't have an understanding of the four kinds of work at this point. The problem is that the book has limited value as the kind of reference guide that would be needed to put these thoughts into actual practice. This is one of the few novels I've ever read that could strongly benefit from an index. It could also strongly benefit from a companion volume that goes through all this in the more traditional manner. I suspect the "IT Ops Handbook" was meant to be that, but its impossible to say since that book does not yet exist. Overall, I recommend this book. Its both a good read with an interesting, if unusual, story to tell, and certainly capable of getting one to think about the right ways to approach IT management.

I bought this book for my husband at his request. He is an IT manager at a major pharmaceutical company. His job consists of many facets including "putting out fires" - managing the tools that monitor servers and working with an engineering team when there is an outage to bring the servers back up in a timely fashion. He works on collaborative projects with the engineering team to streamline the tools that are used to issue tickets to cut down on response time, create accountability, and raise the percentage of success in closing tickets. He is also responsible for the successful deployment of these tools the world over (meaning a lot of business trips). I know this probably sounds like gibberish to a lot of people, but those with an IT background probably know what I'm referring to. He asked me to download this book for him because it was relevant to his job. (Hence the reason for the background I included.) He absolutely loves the book and uses all his free time to read it. This review is therefore courtesy of my husband. This book tells the story of an IT Manager, Bill, who is over budget and late on delivering his project, code-named "The Phoenix Project". The book tells Bill's story, how he overcame his challenges, and what he learned along the way. Being in IT, my husband has often experienced the frustration of being overbudget and delivering projects - sometimes years - late. Often, the frustration and project delays are due to ineffficient communication between his team and the engineering team. This is where part of the book comes in play. A component of this book talks about DevOps. DevOps aids in managing releases of software/tools by standardizing methodology to allow for rapid development and deployment of secure, quality-tested products as well as aiding in automation of these products/software. It teaches strategies for better communication and collaboration between software developers and IT personnel. Therefore, DevOps becomes especially relevant when he is clashing with the engineering team over the development of a new tool. This book is essential for IT organizations as it uses real examples to show the problems IT groups face, how to overcome those challenges, and how to learn from them for the benefit of the company and the individuals who work there. Real-life examples make the book relatable. The humor interspersed in the book makes a subject that can easily turn dry into an entertaining read instead. My husband has learned strategies from this book that he can implement for peak efficiency - both with the tools he manages and the people he manages. If you work in any part of IT, this is a must read that will show you how to effectively cope no matter what is thrown your way.

The Phoenix Project belongs to that rare category of books: a business novel. It's written as fiction but it teaches us something serious. The most well known book in this category is The Goal: A Process of Ongoing Improvement by Dr. Eliyahu M. Goldratt. The Goal is a long-term best selling business book and required reading for nearly every MBA student for the last twenty-five years. What The Goal did for lean manufacturing, The Phoenix Project will do for managing IT. Bill Palmer is the reluctant protagonist who is thrust into managing IT Operations. He inherits a world of hurt: new business innovation projects are so far behind that the corporation's ability to remain competitive is threatened; standard business functions like payroll, data storage, and point of sale systems suffer from recurrent outages like lights flickering during a storm; and the whole IT organization is so buried firefighting that critical maintenance is neglected. I immediately resonated with the situation. In fact, if you work in a business of any size, in IT or not, you'll quickly find similarities. In my day job, over the years I've found myself wondering why small startups can outcompete two hundred person strong development teams, why certain deployments are multi-day affairs that nearly always fail, why we must wait months for to release software, why the releases that do get to the light of day are nearly always missing key features, and why we seem incapable of fixing bugs so awful that we drive our customers away. In The Phoenix Project, the protagonist Bill Palmer encounters all of this and more. It's written as a fast-paced business thriller (I couldn't put it down and spent much of Christmas day hiding from my kids to read -- in fact, once I hit the halfway point, I literally did not stop reading it except for bathroom breaks.) But it's also a serious business book about managing IT. Through an enigmatic board member, Bill is forced to question his assumptions about IT. What is the role of IT Operations, and even all of IT? What are the four kinds of work that IT must do? What's the silent killer of all planned work? What does the business need? Through comparisons with how work is managed in a factory and examples from The Goal, authors Gene Kim, Kevin Behr, and George Spafford show how the time tested techniques of lean manufacturing (also the Toyota Production System) apply to IT work. By applying these principles, Bill Palmer is able to: - Speed up the time it takes from implementation to deployment by reducing work in progress - Increase the amount of useful work completed by reducing dependencies on key resource bottlenecks, whether those are people, hardware, or systems - Reduce outages by addressing technical debt on fragile IT systems (such as old databases, tricky routers, etc.) - Increase the IT contribution to the business by gaining a better understand of the business requirements, and focusing effort on those features that make the largest beneficial impact to the business. One of the authors, Gene Kim, is the original creator of Tripwire, a widely used tool for managing IT changes; cofounder of the company by the same name; and author of The Visible Ops Handbook: Implementing ITIL in 4 Practical and Auditable Steps . I've seen him give talks on these concepts to a packed audience and receive a standing ovation. For years, I've wanted to be able to bring these types of ideas back to my company because I'm convinced we could be ten or a hundred times more effective and delight our customers if only we could overcome our IT dysfunctions. I'm thrilled to see them now in written form. If there was one book I'd want every employee of my company to read, it would be this one.

Reading this book after 10 years in the industry as a developer, and having touched DevOps briefly a few times, this book has taken me on a journey. It explained the why behind some of the best practices already in a lot of companies, that they perhaps lost sight of or don't fully understand, and grounds IT for business where it should be that I as a developer only vaguely understood: the business needs. It also shows how the processes around how work gets done protects not only those business needs but the developers as well, allowing frustrations about competing priorities and demands on time, about being viewed as incompetent despite working your hardest, to be removed so developers can thrive doing what they do best: creating tools that help the business succeed. While I may never be a manager myself, because I love development and dislike office politics, this book was not only a compelling read, but a great, grounding lesson on life in IT that brought to focus parts of my career where I could do better and parts I was taking for granted, without thinking of the why. Love this book and recommend it to anyone in Development, Security, Infrastructure, or even just Management.

Main Idea - IT can use known intellectual capital from manufacturing to drive business centric work to incredibly short cycle times. This book displays a vision for what is being marketed as The Dev-Ops Movement; that is blending development and operations appropriately to create true agility for a market driven IT shop. Summary - The book follows the career of Bill, one of the IT Ops Managers for a billion dollar auto parts manufacturer/distributor/retailer. He is promoted to VP of IT after the two execs above him are fired. The first chapters of the book demonstrate all the bad service, terrible development practices, and daily fires that are present in a "normal shop." Bill is introduced to Erik, a board candidate who has run major improvement efforts in one of the company's manufacturing plants and since moved on to become a consulting guru in all things improvement including IT. Erik mentors Bill in "the Three Ways:" 1) The First Way shows us how to create fast flow of work as it moves from Development into IT Operations 2) The Second Way shows us how to shorten and amplify feedback loops so we can fix quality at the source and avoid rework 3) The Third Way shows us how to create a culture the simultaneously fosters experimentation, learning from failure, and understanding that repetition and practice are the prerequisites to mastery. Bill, with Erik's occasional enigmatic input, goes on to improve and control the flow of work using his key resources as gates for feeding more WIP into IT, aligning IT with key business metrics, and turning his shop into a "game changer," capable of turning deployments with quality, security, and all the other "ilites" taken into consideration and ops controls being added as part of the IT product designs - very cool. This is done through bundling of environments as part of a release packages and using virtual and cloud technologies to automate deployment and test of build packages in minutes instead of weeks. With the constraints of setups and testing being reduced, work can be reduced to one-piece-flows (smaller sets of requirements) which reduced the build, test, and deployment times. All of this of course assumes a great deal in terms intellectual capital and technology but in the book, they are able to reuse scripting and know how they adapt from the Phoenix Project; their $20m 2.5 years in the making, last stab at survival. Thoughts - The improvement theories are sound but do require leadership understanding and commitment. The ideas are excellent adaptations of Theory of Constraints, Lean, Six Sigma, and ITIL. For shops without the in-house expertise of the improvement techniques and technologies involved, the road will be somewhat longer. The authors through their characters assert that this mode of operating will eventually become the new normal and is required for survival. I totally agree. Like most meaningful business changes, they are simple but not simplistic requiring, hard work, focus, determination, and careful thought. This book is descriptive and is to be followed by the proscriptive DEV/OPS Cookbook. The one "buyer beware" I have to a universal endorsement for this this book is it's occasionally strong language. (A few F bombs, 41 s***, 32 Godd**ns - gotta love search capability in Kindle) While some may reason that this reflects the reality of their environment, it will be off putting to many as offensive or unprofessional rendering it "unfit" to share in their work cultures. The book is important and a worthy and worthwhile read which I endorse; however, I fear the authors have limited their market and sphere of influence though their use of profanity. If you are in an environment where the language is unacceptable and you can read it with clear conscience, consider creating a summary for your team. As a companion to this book, I would highly encourage that readers digest a copy of The Goal. (Dr. E.M. Goldratt) and its sequel, It's Not Luck.

I first met Gene Kim at Velocity 2011, where I saw him give a talk about operational excellence. About a year and a half later, at another event, I finally came to him and told him how angry his talk made me. At the time of his talk, what I heard him argue for is rigidity, inflexibility, and avoidance of any sort of creativity or agility. In hindsight, this is hilarious. I've got a few issues with this book; the effort to have the characters stand for a particular IT mindset resulted in all characters being cliched; Gene occasionally hits the reader over the head with a big baseball bat to make sure the reader gets the point he's trying to make. Look, I'll be honest: If Gene was trying to write a standard work of fiction, rather than a parable, I'd say he's pretty average. On the other hand, nobody's buying this book because they're looking for a good thriller to cuddle up with. Other reviewers have, far more eloquently than I could, already talked about the great points this book makes. I agree with all of them, though I'll note that I think it's one of those books you really should commit to finishing (it's not that long. It'll be easy. It's riveting), because in the process of the protagonists (Bill, Wes, Patty) getting to the desired end state, they make some decisions and turns that are decidedly suboptimal and -- frankly -- horrifying. A good example of this is deciding that the only way they can manage the impact of their star performer is by restricting access to him and requiring the approval of the VP of IT (or the star's boss) to simply TALK with him. And that's not just for the whole organization -- that's for the tier 3 engineers who are supposed to learn from him. It's a classic "we have no clue how to manage our environment, so we'll put more controls in place so we can feel we can manage what's going on" maneuver, and I really wish Gene was more explicit in calling this out as the wrong thing. Gene does get to the good stuff, though, and the thing that makes this book so fantastic -- the thing that makes me gush about this book more than I've gushed about any other management or technology book in my memory -- is that the way he does this is incredibly accessible to a broad set of people from a broad set of technology disciplines. I've done my time in a sixty year old accounting company where IT management talked ITIL all day and tried to plan work effort nine months in advance. They'll get value from this book. I work in a company at the forefront of the DevOps trend and this book verbalizes how we think about things -- and how we should continue to improve. Being an ITIL heretic (I believe ITIL's worth is not in forcing more structure, but in defining the common issues that concern everyone in technology and allowing them to collaborate better to address these issues -- almost the opposite of what most ITIL practitioners (certainly the certified ones) seem to believe); being an ardent believer in the power of superstar performers to do great things when completely unleashed from stupid, cumbersome process; and being a religious zealot when it comes to believing in the power of automation to remove the need to do the same thing a whole bunch of times (each time finding a slightly different, inconsistent solution to a problem), I've seen no manifesto that so purely distills my point of view, that so clearly speaks for me and what I believe in. Gene, I owe you a beer. Hell, most of us in technology owe you a beer.

Great book, very pleasant to read but also full of interesting cases.

Highly recommend this book for anyone who has any dealings with IT, whether you are a business person, manager or IT professional. Easy to read and understand the concepts since the entire book is an example of implementing DevOps within IT. And the cover is beautiful!

If you work in IT (heck, even if your business has any IT - so that's all of you), then you should read this book. Regardless of your specific role, I'm certain that you'll learn something useful (and more importantly, actionable). I've changed my approach to doing a few things already based on lessons I've taken from the book and I still need to process some more ideas around how to do stuff better. I expect that I'll be reading it at least one more time through so that I don't miss anything that I could make use of. One month ago, I'd never heard about this book. Of all the interesting and useful things that I took away from the Microsoft Global MVP Summit this November, I suspect that this will have the greatest impact. Fellow PowerShell MVP Steven Murawski often talks about DevOps and recommends this book in his presentations. He's such a fan of the book that he brought a bunch of copies to give out and I was very glad to receive one after hearing him extol its virtues. Having read the first few chapters on the flight back from Seattle, on landing I purchased the Kindle edition from Amazon UK so that I could carry it around on my Kindle and phone in order to reduce the barriers to being able to consume it! Personally, I love the approach that this book takes. By encompassing so much useful information about ITSM, DevOps methodologies and much more in a novel with an engaging storyline, I was able to read it much more easily and quickly that many of the dry technical texts that bog down our industry. I think that it also helped me to digest the information and apply it to my work situation more easily, even though I work in a significantly different type of organisation to that in the story. The bottom line is that this isn't just a good book, it's an important book. You should read it at the first available opportunity. We'll all be the better for it.

O livro conta a história do departamento de TI de uma empresa americana. Como o departamento sai do caos total para um fluxo orquestrado, alinhado e entregando valor ao negócio da empresa, que nada tem a ver com TI. É interessante ver que apesar de tratar de uma empresa privada americana, o setor de TI retratado se assemelha a muitos setores de TI do Brasil, incluindo de órgãos públicos. Em fim. O livro é muito bom. Por se tratar de uma história de ficção com personagens interessantes a leitura flui muito bem. A fluidez da leitura é semelhante ao do livro "A meta", que eu também recomendo. Não é um livro que vai te dar detalhes de como resolver os problemas da TI. Muita das soluções adotadas no livro não são tão simples de serem adotadas na vida real. Mas mesmo assim o livro enche o leitor de motivação para ajudar no desafio de promover mudanças em seu local de trabalho!

The characters are archetypical and relatable. The pace is thrilling, the story unfolds with the learning process of individuals and the organization. It delivers the spirit of DevOps in a way which is respectful and even intimate for IT professionals. I recommend this book for every IT professional, IT manager and other managers on top or depending on IT. I spared one star because, as a roman – as literature, it is not worth much. Very basic language, silly soap opera situations, not philosophical, not poetic, not psychological, not theatrical. It is a management book written as a story which is accessible for a broad public.