Podcasts about service oriented architecture

SummaryIn this conversation, Vaughn Vernon and Udi Dahan discuss various topics related to software architecture, including service-oriented architecture (SOA), event-driven architecture, and sagas. They emphasize the importance of using the right architectural styles and patterns in the right places, rather than over-applying or misapplying them. They also discuss the role of patterns in software development and the need for a common language to facilitate communication among developers. Additionally, they explore the strengths and weaknesses of event-driven architecture and the misconceptions around API-first design. Finally, they delve into the concept of sagas as a way to handle complex business processes and policies.TakeawaysUse the right architectural styles and patterns in the right placesPatterns are important for facilitating communication among developersEvent-driven architecture should not be over-applied or misappliedAPI-first design should consider the actual business processes and not just CRUD operationsSagas can be a useful technique for handling complex business processes and policiesChapters00:00 Introduction and Background04:21 Understanding Service-Oriented Architecture (SOA)09:36 The Role of Patterns in Software Development18:17 Exploring Event-Driven Architecture35:07 The Concept of SagasUdi Dahan is one of the world's foremost experts on Service-Oriented Architecture and Domain-Driven Design and also the creator of NServiceBus, the most popular service bus for .NET. Hosted on Acast. See acast.com/privacy for more information.

W.B.J. WILLIAMS, an author from Massachusetts, will join us for a lively discussion on all of his books; how he generates his ideas; and why he has been so successful! FROM HIS BIO: "An information security executive by day, W. B. J. Williams' secret identity is that he is an author. He also holds advanced degrees in anthropology and archeology, as well as is an avid historian, mystic, and poet. He is noted for his bad puns, and willingness to argue from any perspective. He is endured by his beloved wife and two daughters, and lives in Sharon Massachusetts. When he is not at home or at his computer, he can often be found haunting the various used bookstores of Boston. ​He is the published author of four books, The Garden at the Roof of the World, a novel with Dragonwell Publishingpublished in 2013,  Security for Service Oriented Architecture, non-fiction with Auerbach published in 2014, The Reality, Mythology, and Fantasies of Unicorns with Dragonwell Publishing out September 2021, and How to Create an Information Security Program from Scratch with Auerback out in September 2021. An excerpt from The Hacker of Guantanamo Bay under the title "The InfoCoup" has been published by Abyss and Apex in their October 2019 edition, which was included in their Anthology, The Best of Abyss and Apex volume 3 in 2019. He is a frequent author panelist at ReaderCon and Arisia, and was a panelist at Boskone in 2018. He has conducted readings from his novels and works in progress at ReaderCon, Arisia, Boskone, and other venues. Follow Walt as an author on: Linked-In, Twitter, Facebook, Pinterest, Instagram. He does maintain an InfoSec social network independent of the above." wbj-williams.net/index.html

W.B.J. WILLIAMS, an author from Massachusetts, will join us for a lively discussion on all of his books; how he generates his ideas; and why he has been so successful! FROM HIS BIO: "An information security executive by day, W. B. J. Williams' secret identity is that he is an author. He also holds advanced degrees in anthropology and archeology, as well as is an avid historian, mystic, and poet. He is noted for his bad puns, and willingness to argue from any perspective. He is endured by his beloved wife and two daughters, and lives in Sharon Massachusetts. When he is not at home or at his computer, he can often be found haunting the various used bookstores of Boston. ​He is the published author of four books, The Garden at the Roof of the World, a novel with Dragonwell Publishingpublished in 2013,  Security for Service Oriented Architecture, non-fiction with Auerbach published in 2014, The Reality, Mythology, and Fantasies of Unicorns with Dragonwell Publishing out September 2021, and How to Create an Information Security Program from Scratch with Auerback out in September 2021. An excerpt from The Hacker of Guantanamo Bay under the title "The InfoCoup" has been published by Abyss and Apex in their October 2019 edition, which was included in their Anthology, The Best of Abyss and Apex volume 3 in 2019. He is a frequent author panelist at ReaderCon and Arisia, and was a panelist at Boskone in 2018. He has conducted readings from his novels and works in progress at ReaderCon, Arisia, Boskone, and other venues. Follow Walt as an author on: Linked-In, Twitter, Facebook, Pinterest, Instagram. He does maintain an InfoSec social network independent of the above." wbj-williams.net/index.html

Effective leadership in the fast-paced and dynamic world of technology requires a strategic and adaptable approach. One powerful tool that can significantly enhance leadership skills for a tech leader is a well-defined methodology. By employing a structured and systematic approach to decision-making, problem-solving, and team management, tech leaders can navigate complex challenges with confidence and efficiency. A prime example of how methodology can propel a tech professional's career to great heights is Trevor Wood's remarkable journey at CIBC FirstCaribbean International Bank. Starting as an intern, Trevor demonstrated a keen understanding of the importance of methodical thinking in technology projects. Through continuous learning and application of best practices, he ascended through the ranks and now holds the prestigious position of Director - Data, Wealth & Corporate Centre Technology. Trevor's success story underscores the transformative potential of methodology in shaping a tech leader's career trajectory and impact within their organization.Here's more about Trevor WoodSpecialties: Data Science, Analytics, Data Warehousing, Business Intelligence, Reporting, ETL Development, Database Development, IT Governance, IT Architecture, IT Systems Design, Service Oriented Architecture, Master Data Management, Data Governance, Agile Methodologies.http://www.cibcfcib.com/

Udi Dahan is one of the world's foremost experts on Service-Oriented Architecture and Domain-Driven Design and is also the creator of NServiceBus; the most popular service bus for .NET. Udi joined us back on Episode 32 to discuss Microservices.   Topics of Discussion: [2:47] Udi talks about some of the changes, and similarities, in distributed computing in the last five years as well as generational differences to approach learning. [11:27] Udi defines what a service mesh is and when it's applicable. [14:46] Udi discusses his concerns regarding using a service mesh and common problems encountered. [22:28] With most of the new generation of programmers using Web service-based programming, what does Udi think they need to hear? [27:50] Why Udi thinks the larger companies and vendors need to take more responsibility and “do more good.” [32:48] Udi shares more on NServiceBus's offerings and functionality and why developers need to learn more. [36:36] Are there any pieces of NServiceBus that will need more than just a .NET standard support?   Mentioned in this Episode: Architect Tips — New video podcast! Azure DevOps Clear Measure (Sponsor) .NET DevOps for Azure: A Developer's Guide to DevOps Architecture the Right Way, by Jeffrey Palermo — Available on Amazon! Jeffrey Palermo's YouTube Jeffrey Palermo's Twitter — Follow to stay informed about future events! Particular Software — NServiceBus Episode 32 — Microservices   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.   Quotes: “Every generation of programmers needs to relearn kind of the same points over again.” — Udi [3:51] “We're still essentially coming up with new generations of technologies that are addressing the same category of problems.” — Udi [6:16] “The problem is not rooted in what do they need to hear so much as who do they need to hear it from.”— Udi [23:51] “If you know a thing, if you can help, then you should.” — Udi [29:47] “NServiceBus essentially takes all of the problems that you never want to have, and the challenges that most people don't know that they're going to have so they don't appreciate it until they have it, and essentially prevents them from happening.”— Udi [34:29] “That ounce of prevention is equivalent to a pound of cure.” — Udi [34:46]   Udi: Website | Twitter

Rudi Steyn is the Chief Technology Officer (CTO) at CoTé Software & Solutions, a tech company that offers management SaaS solutions for all industries. Their main office is in Australia, but they also have offices in the US and Singapore. As CTO, Rudi sets the roadmap for its various services and assists in its Digital Customer Experience strategies. Rudi also endorses the latest service for agencies called AGENCYMATE. AGENCYMATE is a platform that serves as a virtual extension of an agency to provide various marketing and sales solutions.   Rudi joins us to discuss his role as CTO and how AGENCYMATE supports agencies, big or small. He shares what it was like  growing up in South Africa and the differences he noticed in lifestyles when he moved to Australia. He explains how he joined the insurance industry and how the pandemic made industries leap into a more digital future. Rudi also describes the changes we need to make regarding management styles and why hackers no longer target computers as much as they target people. "Management style has to change. We should change our focus from management-based to outcome-based." - Rudi Steyn Today on Spot On Insurance: Growing up in South Africa How sports taught Rudi how to work with different kinds of people The differences between living in South Africa and Australia Why Rudi pursued a career in insurance Rudi's everyday responsibilities as a CTO What AGILE and Scrum brought to the technology world How Service-Oriented Architecture (SOA) helps distribute the computational logic of the system What Rudi classifies as a digital experience Why hackers are now targeting humans over computers Reinforcing a culture of cybersecurity in your organization The experience clients can expect when using AGENCYMATE What businesses should focus on following a pandemic The driving factors behind The Great Resignation How the pandemic demanded a change in management styles Key Takeaways: Not having the ability to fail fast, learn, and pivot is hampering a lot of organizations. Everything has gotten faster and we're still time-poor as a collective.

In this episode we talk about the monolith, SOA, microservices, and why each makes sense under certain circumstances. We cover the technical aspects as well as the organizational components of choosing an approach. Service Oriented Architecture (https://en.wikipedia.org/wiki/Service-oriented_architecture) Microservices (https://en.wikipedia.org/wiki/Microservices) GraphQL (https://graphql.org/) Citadel pattern (https://m.signalvnoise.com/the-majestic-monolith-can-become-the-citadel/) You can reach us via email at hosts@expandingbeyond.it (mailto:hosts@expandingbeyond.it). You can follow us on Twitter at @podcast_eb (https://twitter.com/podcast_eb). Where to find Monica on the internet: Twitter: @KFMolli (https://twitter.com/KFMolli) Github: @nirnaeth (https://github.com/nirnaeth) Blog: dev.to/nirnaeth (https://dev.to/nirnaeth) Where to find Urban on the internet: Twitter: @ujh (https://twitter.com/ujh) Github: @ujh (https://github.com/ujh/) Blog: urbanhafner.com (https://urbanhafner.com/) The intro and outro music is Our Big Adventure (https://freemusicarchive.org/music/Scott_Holmes/Happy_Music/Our_Big_Adventure) by Scott Holmes (https://freemusicarchive.org/music/Scott_Holmes). It's licensed under Attribution-NonCommercial 4.0 International (CC BY-NC 4.0) (https://creativecommons.org/licenses/by-nc/4.0/).

Veronika Schmid-Lutz and Rüdiger Fritz from SAP tell us, what value SAP sees in OPC UA. They talk about Business Context Driven Control Loops and the benefit of Service Oriented Architecture on the shop floor.

Jim Frazer sits down with Benson Hougland from Opto 22 at the 2020 ARC Forum in Orlando. They discuss MQTT and Desalination Systems application, as well as their participation at the 2020 ARC Orlando Forum.

Randy is part of a team focused on building a Service Oriented Architecture with Go. Don figures out he has always been using services, but the SOA acronym seemed to involve more than simply work. Randy explains further the use of messages, queues, and other approaches to request buffering.

Randy is part of a team focused on building a Service Oriented Architecture with Go. Don figures out he has always been using services, but the SOA acronym seemed to involve more than simply work. Randy explains further the use of messages, queues, and other approaches to request buffering.

Testing in autonomous teams - speed is everything The role of testers has evolved in the last decade. Test automation has become the norm. So, testers have grown more towards developers.What this episode coversWhat are the skills they need to succeed? With the rise of autonomous teams and product teams, more and more tasks of testers moved to other roles like developers. What knowledge must be spread over these roles to ensure that we can release to PRO without fearing what will happen?And there have been other evolutions like the one to more micro-service-oriented architectures and companies moving to the cloud. Both coming with their own challenges. What is the impact on testing and testers?GuestsJoost van Wollingen; Consultant Quality and Test Automation at Xebia and former colleague at bol.com in a test role. The lead of the test guild. Who has grown really close to a software engineer? We have worked together in several settings here;Ivo de Bruijn; Software engineer at bol.com who started in a test role;Notesand Promotional Code for EXPAND*Expand ConferenceThe EXPAND Conference 2019 brings together every IT discipline, for an in-depth look at the value and difference every role brings. We will learn new ways of working together and sharing our knowledge, with a focus on mastery in engineering teams.For conference info, go here: conference infoSignup and get 10% reduction. Pay 225,- instead of 250,-, use this link or use the code Techlab2019 in the Eventbrite checkout**.Other notesIsolated testing - replacing the way testing in DEV and TEST was done. No more dependenciesTechnical Aspects (like the introduction of Service Oriented Architecture) and Cultural Aspects (like the introduction of You Build It, You Run It, You love It) are both influencing the way testing is approachedSpeed is key. if you create a fast feedback loop and it only needs 5 minutes to build, you stay in your context.Shift Left vs Shift Right is explained. Earlier testing on DEV and do more on PRO.*exclusive for Techlab Visitors** as long as tickets are available

In dieser Folge geht es um Feathers.js, worüber wir mit Sean Nicholas “Nick” Dieterle sprechen. Feathers.js ist ein Javascript-Framework, das sich auf das Mindeste reduziert, aber dabei einen Haufen Features mit sich bringt. Allem voran Realtimeness out of the box. Nick plaudert aus dem Nähkästchen und erzählt uns alles, was man über Feather.js wissen muss. Picks of the Day Nick: Deep Learning Kurs Awesome Feathers.js Sebi: Unicode Property Escapes Fabi: Easter-Egg im Speedtest von Ookla Schreibt uns! Schickt uns eure Themenwünsche und euer Feedback. podcast@programmier.bar Folgt uns! Bleibt auf dem Laufenden über zukünftige Folgen und Meetups und beteiligt euch an Community-Diskussionen. Twitter Instagram Facebook Meetup YouTube Erfahrt hier, wann das nächste Meetup in unserem Office in Bad Nauheim stattfindet. Meetup Musik: Hanimo

Podcast: This week on the show, we speak by telephone with Robin Bloor, author of To Fathom The Gist: Approaches to the Writings of G.I. Gurdjieff and The Arch-Absurd. This conversation ranges from the writings of G. I. Gurdjieff, to how to approach their seemingly impenetrable nature, to the cosmology of the Gurdjieff tradition and how to translate such considerations into practical work on Self. Mr. Bloor was born in Liverpool, England in the 1950s, studied Mathematics at Nottingham University, and eventually became a computer consultant. Aside from his consultancy work he has established a reputation as an international speaker on technology topics and as a writer by virtue of many magazine articles and technical publications. In April 1999 he published his first book, The Electronic B@zaar, which was about the dot com revolution. Much to his surprise it was a UK business best seller and was published a year later in the US, just as the dot com boom turned to bust. It received several accolades, being referred to as "a classic" by Publisher's Weekly in the US. He has been involved in The Gurdjieff Work since 1982. In 1988 he met and became a pupil of Rina Hands, an accomplished Gurdjieff Movements teacher, and an inspirational group leader, who died in 1994. In recent years Mr. Bloor has turned his attention to writing about The Gurdjieff Work, and is widely regarded as an expert on Gurdjieff's writings. His series of books under the common title of To Fathom The Gist deal directly with the inner meaning of Gurdjieff's writings. They are gradually being rolled out year by year. Robin is also an attendee and participant in the All & Everything International Conference which takes place every year and focuses on Gurdjieff's writings. Robin immigrated to the US in 2002, settling in Texas. In 2003 he was awarded an honorary Ph.D. in Computer Science by Wolverhampton University in the UK in recognition of 'Services to the IT Industry'. From 2004 to 2007 he participated in writing three Dummies books on technology: Service Oriented Architecture for Dummies, Service Management for Dummies and Cloud Computing for Dummies. More information about Robin Bloor's work can be found at: Austin Gurdjieff Society Website: austingurdjieffsociety.weebly.com, To Fathom the Gist Website: www.tofathomthegist.com, Robin Bloor's email address: robin.bloor @ gmail.com.

A deep discussion microservices and data, aggregating the query and recommendations to reduce the binding between the data sets. An overview of types of database that suit the transactionable requirements of the business and the stakeholder. Ideally, each microservice class should have exclusive private access to a schema, but often business and engineering break the rules, but why?

In this podcast @AndyPalmer from @Tamr sat with @Vishaltx from @AnalyticsWeek to talk about the emergence/need/market for Data Ops, a specialized capability emerging from merging data engineering and dev ops ecosystem due to increased convoluted data silos and complicated processes. Andy shared his journey on what some of the businesses and their leaders are doing wrong and how businesses need to rethink their data silos to future proof themselves. This is a good podcast for any data leader thinking about cracking the code on getting high-quality insights from data. Timelines: 0:28 Andy's journey. 4:56 What's Tamr? 6:38 What's Andy's role in Tamr. 8:16 What's data ops? 13:07 Right time for business to incorporate data ops. 15:56 Data exhaust vs. data ops. 21:05 Tips for executives in dealing with data. 23:15 Suggestions for businesses working with data. 25:48 Creating buy-in for experimenting with new technologies. 28:47 Using data ops for the acquisition of new companies. 31:58 Data ops vs. dev ops. 36:40 Big opportunities in data science. 39:35 AI and data ops. 44:28 Parameters for a successful start-up. 47:49 What still surprises Andy? 50:19 Andy's success mantra. 52:48 Andy's favorite reads. 54:25 Final remarks. Andy's Recommended Read: Enlightenment Now: The Case for Reason, Science, Humanism, and Progress by Steven Pinker https://amzn.to/2Lc6WqK The Three-Body Problem by Cixin Liu and Ken Liu https://amzn.to/2rQyPvp Andy's BIO: Andy Palmer is a serial entrepreneur who specializes in accelerating the growth of mission-driven startups. Andy has helped found and/or fund more than 50 innovative companies in technology, health care, and the life sciences. Andy's unique blend of strategic perspective and disciplined tactical execution is suited to environments where uncertainty is the rule rather than the exception. Andy has a specific passion for projects at the intersection of computer science and the life sciences. Most recently, Andy co-founded Tamr, a next-generation data curation company, and Koa Labs, a start-up club in the heart of Harvard Square, Cambridge, MA. Specialties: Software, Sales & Marketing, Web Services, Service Oriented Architecture, Drug Discovery, Database, Data Warehouse, Analytics, Startup, Entrepreneurship, Informatics, Enterprise Software, OLTP, Science, Internet, eCommerce, Venture Capital, Bootstrapping, Founding Team, Venture Capital firm, Software companies, early-stage venture, corporate development, venture-backed, venture capital fund, world-class, stage venture capital About #Podcast: #FutureOfData podcast is a conversation starter to bring leaders, influencers, and lead practitioners to discuss their journey to create the data-driven future. Podcast link: https://futureofdata.org/emergence-of-dataops-age-andypalmer-futureofdata-podcast/ Wanna Join? If you or any you know wants to join in, Register your interest and email at info@analyticsweek.com Want to sponsor? Email us @ info@analyticsweek.com Keywords: #FutureOfData #DataAnalytics #Leadership #Podcast #BigData #Strategy

My JS Story Cory House On this Episode we have another JS Story, and this time it’s with Cory House, a Pluralsight author, software architect for Cox Automotive, and a consultant with a focus on React. Listen to Charles Max Wood and Cory discuss a bit about how Cory got into programming, how learning how to learn is vital to being a talented developer, as well as using documentation as your development environment to ensure your code’s documentation doesn’t fall behind. This and more right here. Stay tuned. How did you get into programming? Cory starts his story as a business major in college but had interest in computers. He spent time around various computers and machines, giving him experience in various operating systems and platforms. On any given day he would be using any of three different operating systems. His interest in computers inspired him to double major. He started learning Cobalt and Visual Basic and C++. He talks about being interested in web development, including Flash. He specialized in Flash throughout college, as well as early on in his software development career. He also talks a bit about that the open web seems to innovate in a way that keeps it relevant. He talks about using Flash to make websites with entering screens and animations and now that is obsolete. Charles mentions that it’s interesting that his main interest was business and computers became something he was interested in later on and that you don’t have to be someone who started young to be proficient. Cory talks about being driven to catch up, being around people who knew things off the top of their head while he was still asking questions and looking things up. Learning How to Learn Out of college Cory found that he had a degree, but what he had really learned was how to learn. He never used Cobalt, C ++, or visual basic after school. Learning how to learn combined with being able to create a focus on a specific technology are vital. Charles adds that he would hear often that it took being a natural in programming to get it, and that maybe being a natural was really just being someone who has learned how to learn and to focus. Getting Good With Your Craft Cory mentions that working with someone who head and shoulders ahead of everyone else. They were working in Unix and seemed to know every single Unix command and flag. He found it inspiring to see someone take the craft so seriously and to learn a specific technologies tool with so much dedication. Some technologies will be so important that they will be key technologies that will still be useful many years later. Cory suggests that one of those tools seem to be JavaScript. JavaScript is almost mandatory in frontend web development. Additionally, JavaScript is reaching into other new technology types including IoT and VR and other places, constantly expanding. How did you get into JavaScript? Cory talks about how it really all got started when Steve Jobs killed Flash. He opened his mind to other technologies and started working with JavaScript. Remembering learning jQuery, he found himself really enjoying it. He started building online business applications. Browser inconsistencies were a huge issue, making it so that you’d have to check your work on each browser to make sure it worked cross platform. Things are moving so quickly that being a full stack developer is becoming less and less prevalent, to the point where he considers himself primarily a JavaScript developer. Being an expert in a single technology can make you really valuable. Companies are running into issues with not finding enough people that are experts in a single tech. Cory suggests that employers should find employees that seem interested and help allow them to focus and learn whatever that tech is. Charles talks about the split between developers that tend to lean full stack and plug in technologies when they need it versus developers that work exclusively in front end. He suggests it may be a case by case situation. Service Oriented Architecture Cory suggests that service oriented architecture movement has moved us that way. Once you have a set of services set up, it becomes more realistic to turn on the front end. If there were a good set of services there, Cory adds that he doesn’t think he would be able to build services faster using a server side framework like Rails, Django, or ASP.Net MVC than he could in React today using something like create React app. The front end has become much more mature. Cory mentions that he has had good experiences with ASP.Net NPC and Visual Basic being a Microsoft stack developer. He adds that he doesn’t feel like he has given up anything working with JavaScript. He adds that with the nesting of different models together, he gets to reuse a lot of code in server side development. NPM makes it easy to stand up a new package. If you are planning to create an API, it becomes much harder to use a server side rendering stack, with so many APIs available, it’s a logical move to go client side. Possible Future for Front-end and Back-end Roles Charles brings up that the development of things like VR are making changes in the roles that front end and back end development play. The front end will more to taking care of the overall application development of apps, while the back end will become supporting roles as services and APIs. New technology like VR and artificial intelligence will need a high amount of computing power on the backend. The front end will focus more on the overall experience, display, and the way we react with things. Charles talks about how the web may move away from being just an HTML platform. He says that it will be interesting to find where JavaScript and frameworks like React will fall into this shift into this next generation. We already are seeing some of this with the capabilities with canvases, WebVR, and SVG and how they are changing how we experience the web. Reasonable Component Story Cory brings up being interested in the Reasonable component story. Sharing code from a traditional web app, to a native app, and to potentially a VR app as well is exciting and he hopes to see it flesh out more in the coming years. He talks about going to conferences and how much we have built and how much we don’t have easily sharable innovation. He hopes to see it solved in the next few years. What contributions have you made to the JavaScript community? Cory mentions working on the open source project Slingshot. He was trying to solve issues that many found in React. React isn’t very opinionated. React is for writing reasonable components for the web, but it doesn’t have opinions on how you structure your files, how you minify, bundle, deploy, or make API calls, etc. He realized that telling people to use React and to deal with those issues wasn’t reasonable. He created React Slingshot as a development boilerplate. He put it to use in many applications and it became popular. It’s easy because it did things like allow you to run NPM to pull independencies and pull a file, it would fire up a web browser, watch your files, run tests, hot reloading on save, and had a running Redux application build it. It allowed people to get started very quickly. He talks about how he wasn’t the only person trying to solve this issue. He says that if you look now there are well over one hundred boiler plates for React that do similar things. Most popular being Create React App. Contributions outside of this, he talks about editing documentation on open source projects being part of his biggest contribution, writing it in markdown and then making pull requests. What are you working on now? Cory adds that he just finished his 7th or 8th Pluralsight course on creating usable React components. At work they create their own reusable React component library. He says that he realizes that it’s a complicated process, where all decisions you make, in order to have a reusable component story, you have to make a lot of decisions. Things like how granular to make the components, reusable styles and how they are packaged, how they are hosted, will it be open or source, etc. Publicly Closed - Internally Open Source Projects Cory talks about the idea of having it as a closed source project, but treating it like an internal open source project for the company, having many people feel invested into the project. He found creating the documentation story was the toughest part. Having solid documentation story that helps with showing how to use the components and it’s features and behaviors. He spends much of his type looking at other documents to help him come up with ways to create his own. He talks about generating the documents automatically with the updates so that they are always in sync. Charles adds that documentation syncing often happens right in the comments, which are also acceptable to being outdated. Pull-request-Template.md Cory adds that a useful way to allow for well documented and safe pull requests is to make a pull request template in GitHub by creating a file called pull-request-template.md so that any time someone makes a pull request, that .md template will populate the pull request. Cory has a checklist for a pull request like making sure there are tests for any new components, the file name should have an uppercase character, is there a ticket open, etc. All of the basic things that should happen in a pull will be in the pull-request-template.md. Charles adds that documentation is one of the things that gets ignored. Having a standard process is very important, more so than getting the job done faster. Also having an outlined expectation for how it’s delivered is important as well. Documentation as Development Environment A useful trick that Cory uses, is using the documentation as the development environment. Anytime they are working on a new component, they start with a documentation site, making changes within the documentation and then it hot loading your changes live. This way your documentation is front of mind and keeps the documentation fall behind. Why React instead of the other frameworks? Cory says that he can sum up React in a single sentence. He says that your HTML sits right in the JavaScript. Which usually sounds bad to a large group of developers. He expects people to react negatively when he talks about it. What he has run into as a common problem, is people separating concerns by filetype and technology, but with React he seems the common problems in terms of components. Cory says that components are the future. Industries that have matured utilize components. For example car manufacturers or even electronic manufactures build things in modules and components. Things that are reusable should be encapsulated into a component instead of trying to hold it in our heads. This makes it so things look the same and reduces many mistakes. You can create components in different frameworks, but React co-mingles markup and javascript with something like JSX. You’re not writing HTML, you’re writing JSX that boils down to HTML. That one element is fundamentally what makes React easier to Cory. For the most part, React can be learned by JavaScript developers in less than a day because many of the things you need to do in React, is just basic JavaScript. Charles adds that components are a concept coming up in various frameworks and is becoming more popular. Picks Cory’s Cory’s React Courses on Pluralsight Essentialism the book Charles’ Get a Better Job Course Angular Remote Conf (now Ruby Dev Summit) React Podcast Kickstarter Links Cory’s Twitter

My JS Story Cory House On this Episode we have another JS Story, and this time it’s with Cory House, a Pluralsight author, software architect for Cox Automotive, and a consultant with a focus on React. Listen to Charles Max Wood and Cory discuss a bit about how Cory got into programming, how learning how to learn is vital to being a talented developer, as well as using documentation as your development environment to ensure your code’s documentation doesn’t fall behind. This and more right here. Stay tuned. How did you get into programming? Cory starts his story as a business major in college but had interest in computers. He spent time around various computers and machines, giving him experience in various operating systems and platforms. On any given day he would be using any of three different operating systems. His interest in computers inspired him to double major. He started learning Cobalt and Visual Basic and C++. He talks about being interested in web development, including Flash. He specialized in Flash throughout college, as well as early on in his software development career. He also talks a bit about that the open web seems to innovate in a way that keeps it relevant. He talks about using Flash to make websites with entering screens and animations and now that is obsolete. Charles mentions that it’s interesting that his main interest was business and computers became something he was interested in later on and that you don’t have to be someone who started young to be proficient. Cory talks about being driven to catch up, being around people who knew things off the top of their head while he was still asking questions and looking things up. Learning How to Learn Out of college Cory found that he had a degree, but what he had really learned was how to learn. He never used Cobalt, C ++, or visual basic after school. Learning how to learn combined with being able to create a focus on a specific technology are vital. Charles adds that he would hear often that it took being a natural in programming to get it, and that maybe being a natural was really just being someone who has learned how to learn and to focus. Getting Good With Your Craft Cory mentions that working with someone who head and shoulders ahead of everyone else. They were working in Unix and seemed to know every single Unix command and flag. He found it inspiring to see someone take the craft so seriously and to learn a specific technologies tool with so much dedication. Some technologies will be so important that they will be key technologies that will still be useful many years later. Cory suggests that one of those tools seem to be JavaScript. JavaScript is almost mandatory in frontend web development. Additionally, JavaScript is reaching into other new technology types including IoT and VR and other places, constantly expanding. How did you get into JavaScript? Cory talks about how it really all got started when Steve Jobs killed Flash. He opened his mind to other technologies and started working with JavaScript. Remembering learning jQuery, he found himself really enjoying it. He started building online business applications. Browser inconsistencies were a huge issue, making it so that you’d have to check your work on each browser to make sure it worked cross platform. Things are moving so quickly that being a full stack developer is becoming less and less prevalent, to the point where he considers himself primarily a JavaScript developer. Being an expert in a single technology can make you really valuable. Companies are running into issues with not finding enough people that are experts in a single tech. Cory suggests that employers should find employees that seem interested and help allow them to focus and learn whatever that tech is. Charles talks about the split between developers that tend to lean full stack and plug in technologies when they need it versus developers that work exclusively in front end. He suggests it may be a case by case situation. Service Oriented Architecture Cory suggests that service oriented architecture movement has moved us that way. Once you have a set of services set up, it becomes more realistic to turn on the front end. If there were a good set of services there, Cory adds that he doesn’t think he would be able to build services faster using a server side framework like Rails, Django, or ASP.Net MVC than he could in React today using something like create React app. The front end has become much more mature. Cory mentions that he has had good experiences with ASP.Net NPC and Visual Basic being a Microsoft stack developer. He adds that he doesn’t feel like he has given up anything working with JavaScript. He adds that with the nesting of different models together, he gets to reuse a lot of code in server side development. NPM makes it easy to stand up a new package. If you are planning to create an API, it becomes much harder to use a server side rendering stack, with so many APIs available, it’s a logical move to go client side. Possible Future for Front-end and Back-end Roles Charles brings up that the development of things like VR are making changes in the roles that front end and back end development play. The front end will more to taking care of the overall application development of apps, while the back end will become supporting roles as services and APIs. New technology like VR and artificial intelligence will need a high amount of computing power on the backend. The front end will focus more on the overall experience, display, and the way we react with things. Charles talks about how the web may move away from being just an HTML platform. He says that it will be interesting to find where JavaScript and frameworks like React will fall into this shift into this next generation. We already are seeing some of this with the capabilities with canvases, WebVR, and SVG and how they are changing how we experience the web. Reasonable Component Story Cory brings up being interested in the Reasonable component story. Sharing code from a traditional web app, to a native app, and to potentially a VR app as well is exciting and he hopes to see it flesh out more in the coming years. He talks about going to conferences and how much we have built and how much we don’t have easily sharable innovation. He hopes to see it solved in the next few years. What contributions have you made to the JavaScript community? Cory mentions working on the open source project Slingshot. He was trying to solve issues that many found in React. React isn’t very opinionated. React is for writing reasonable components for the web, but it doesn’t have opinions on how you structure your files, how you minify, bundle, deploy, or make API calls, etc. He realized that telling people to use React and to deal with those issues wasn’t reasonable. He created React Slingshot as a development boilerplate. He put it to use in many applications and it became popular. It’s easy because it did things like allow you to run NPM to pull independencies and pull a file, it would fire up a web browser, watch your files, run tests, hot reloading on save, and had a running Redux application build it. It allowed people to get started very quickly. He talks about how he wasn’t the only person trying to solve this issue. He says that if you look now there are well over one hundred boiler plates for React that do similar things. Most popular being Create React App. Contributions outside of this, he talks about editing documentation on open source projects being part of his biggest contribution, writing it in markdown and then making pull requests. What are you working on now? Cory adds that he just finished his 7th or 8th Pluralsight course on creating usable React components. At work they create their own reusable React component library. He says that he realizes that it’s a complicated process, where all decisions you make, in order to have a reusable component story, you have to make a lot of decisions. Things like how granular to make the components, reusable styles and how they are packaged, how they are hosted, will it be open or source, etc. Publicly Closed - Internally Open Source Projects Cory talks about the idea of having it as a closed source project, but treating it like an internal open source project for the company, having many people feel invested into the project. He found creating the documentation story was the toughest part. Having solid documentation story that helps with showing how to use the components and it’s features and behaviors. He spends much of his type looking at other documents to help him come up with ways to create his own. He talks about generating the documents automatically with the updates so that they are always in sync. Charles adds that documentation syncing often happens right in the comments, which are also acceptable to being outdated. Pull-request-Template.md Cory adds that a useful way to allow for well documented and safe pull requests is to make a pull request template in GitHub by creating a file called pull-request-template.md so that any time someone makes a pull request, that .md template will populate the pull request. Cory has a checklist for a pull request like making sure there are tests for any new components, the file name should have an uppercase character, is there a ticket open, etc. All of the basic things that should happen in a pull will be in the pull-request-template.md. Charles adds that documentation is one of the things that gets ignored. Having a standard process is very important, more so than getting the job done faster. Also having an outlined expectation for how it’s delivered is important as well. Documentation as Development Environment A useful trick that Cory uses, is using the documentation as the development environment. Anytime they are working on a new component, they start with a documentation site, making changes within the documentation and then it hot loading your changes live. This way your documentation is front of mind and keeps the documentation fall behind. Why React instead of the other frameworks? Cory says that he can sum up React in a single sentence. He says that your HTML sits right in the JavaScript. Which usually sounds bad to a large group of developers. He expects people to react negatively when he talks about it. What he has run into as a common problem, is people separating concerns by filetype and technology, but with React he seems the common problems in terms of components. Cory says that components are the future. Industries that have matured utilize components. For example car manufacturers or even electronic manufactures build things in modules and components. Things that are reusable should be encapsulated into a component instead of trying to hold it in our heads. This makes it so things look the same and reduces many mistakes. You can create components in different frameworks, but React co-mingles markup and javascript with something like JSX. You’re not writing HTML, you’re writing JSX that boils down to HTML. That one element is fundamentally what makes React easier to Cory. For the most part, React can be learned by JavaScript developers in less than a day because many of the things you need to do in React, is just basic JavaScript. Charles adds that components are a concept coming up in various frameworks and is becoming more popular. Picks Cory’s Cory’s React Courses on Pluralsight Essentialism the book Charles’ Get a Better Job Course Angular Remote Conf (now Ruby Dev Summit) React Podcast Kickstarter Links Cory’s Twitter

My JS Story Cory House On this Episode we have another JS Story, and this time it’s with Cory House, a Pluralsight author, software architect for Cox Automotive, and a consultant with a focus on React. Listen to Charles Max Wood and Cory discuss a bit about how Cory got into programming, how learning how to learn is vital to being a talented developer, as well as using documentation as your development environment to ensure your code’s documentation doesn’t fall behind. This and more right here. Stay tuned. How did you get into programming? Cory starts his story as a business major in college but had interest in computers. He spent time around various computers and machines, giving him experience in various operating systems and platforms. On any given day he would be using any of three different operating systems. His interest in computers inspired him to double major. He started learning Cobalt and Visual Basic and C++. He talks about being interested in web development, including Flash. He specialized in Flash throughout college, as well as early on in his software development career. He also talks a bit about that the open web seems to innovate in a way that keeps it relevant. He talks about using Flash to make websites with entering screens and animations and now that is obsolete. Charles mentions that it’s interesting that his main interest was business and computers became something he was interested in later on and that you don’t have to be someone who started young to be proficient. Cory talks about being driven to catch up, being around people who knew things off the top of their head while he was still asking questions and looking things up. Learning How to Learn Out of college Cory found that he had a degree, but what he had really learned was how to learn. He never used Cobalt, C ++, or visual basic after school. Learning how to learn combined with being able to create a focus on a specific technology are vital. Charles adds that he would hear often that it took being a natural in programming to get it, and that maybe being a natural was really just being someone who has learned how to learn and to focus. Getting Good With Your Craft Cory mentions that working with someone who head and shoulders ahead of everyone else. They were working in Unix and seemed to know every single Unix command and flag. He found it inspiring to see someone take the craft so seriously and to learn a specific technologies tool with so much dedication. Some technologies will be so important that they will be key technologies that will still be useful many years later. Cory suggests that one of those tools seem to be JavaScript. JavaScript is almost mandatory in frontend web development. Additionally, JavaScript is reaching into other new technology types including IoT and VR and other places, constantly expanding. How did you get into JavaScript? Cory talks about how it really all got started when Steve Jobs killed Flash. He opened his mind to other technologies and started working with JavaScript. Remembering learning jQuery, he found himself really enjoying it. He started building online business applications. Browser inconsistencies were a huge issue, making it so that you’d have to check your work on each browser to make sure it worked cross platform. Things are moving so quickly that being a full stack developer is becoming less and less prevalent, to the point where he considers himself primarily a JavaScript developer. Being an expert in a single technology can make you really valuable. Companies are running into issues with not finding enough people that are experts in a single tech. Cory suggests that employers should find employees that seem interested and help allow them to focus and learn whatever that tech is. Charles talks about the split between developers that tend to lean full stack and plug in technologies when they need it versus developers that work exclusively in front end. He suggests it may be a case by case situation. Service Oriented Architecture Cory suggests that service oriented architecture movement has moved us that way. Once you have a set of services set up, it becomes more realistic to turn on the front end. If there were a good set of services there, Cory adds that he doesn’t think he would be able to build services faster using a server side framework like Rails, Django, or ASP.Net MVC than he could in React today using something like create React app. The front end has become much more mature. Cory mentions that he has had good experiences with ASP.Net NPC and Visual Basic being a Microsoft stack developer. He adds that he doesn’t feel like he has given up anything working with JavaScript. He adds that with the nesting of different models together, he gets to reuse a lot of code in server side development. NPM makes it easy to stand up a new package. If you are planning to create an API, it becomes much harder to use a server side rendering stack, with so many APIs available, it’s a logical move to go client side. Possible Future for Front-end and Back-end Roles Charles brings up that the development of things like VR are making changes in the roles that front end and back end development play. The front end will more to taking care of the overall application development of apps, while the back end will become supporting roles as services and APIs. New technology like VR and artificial intelligence will need a high amount of computing power on the backend. The front end will focus more on the overall experience, display, and the way we react with things. Charles talks about how the web may move away from being just an HTML platform. He says that it will be interesting to find where JavaScript and frameworks like React will fall into this shift into this next generation. We already are seeing some of this with the capabilities with canvases, WebVR, and SVG and how they are changing how we experience the web. Reasonable Component Story Cory brings up being interested in the Reasonable component story. Sharing code from a traditional web app, to a native app, and to potentially a VR app as well is exciting and he hopes to see it flesh out more in the coming years. He talks about going to conferences and how much we have built and how much we don’t have easily sharable innovation. He hopes to see it solved in the next few years. What contributions have you made to the JavaScript community? Cory mentions working on the open source project Slingshot. He was trying to solve issues that many found in React. React isn’t very opinionated. React is for writing reasonable components for the web, but it doesn’t have opinions on how you structure your files, how you minify, bundle, deploy, or make API calls, etc. He realized that telling people to use React and to deal with those issues wasn’t reasonable. He created React Slingshot as a development boilerplate. He put it to use in many applications and it became popular. It’s easy because it did things like allow you to run NPM to pull independencies and pull a file, it would fire up a web browser, watch your files, run tests, hot reloading on save, and had a running Redux application build it. It allowed people to get started very quickly. He talks about how he wasn’t the only person trying to solve this issue. He says that if you look now there are well over one hundred boiler plates for React that do similar things. Most popular being Create React App. Contributions outside of this, he talks about editing documentation on open source projects being part of his biggest contribution, writing it in markdown and then making pull requests. What are you working on now? Cory adds that he just finished his 7th or 8th Pluralsight course on creating usable React components. At work they create their own reusable React component library. He says that he realizes that it’s a complicated process, where all decisions you make, in order to have a reusable component story, you have to make a lot of decisions. Things like how granular to make the components, reusable styles and how they are packaged, how they are hosted, will it be open or source, etc. Publicly Closed - Internally Open Source Projects Cory talks about the idea of having it as a closed source project, but treating it like an internal open source project for the company, having many people feel invested into the project. He found creating the documentation story was the toughest part. Having solid documentation story that helps with showing how to use the components and it’s features and behaviors. He spends much of his type looking at other documents to help him come up with ways to create his own. He talks about generating the documents automatically with the updates so that they are always in sync. Charles adds that documentation syncing often happens right in the comments, which are also acceptable to being outdated. Pull-request-Template.md Cory adds that a useful way to allow for well documented and safe pull requests is to make a pull request template in GitHub by creating a file called pull-request-template.md so that any time someone makes a pull request, that .md template will populate the pull request. Cory has a checklist for a pull request like making sure there are tests for any new components, the file name should have an uppercase character, is there a ticket open, etc. All of the basic things that should happen in a pull will be in the pull-request-template.md. Charles adds that documentation is one of the things that gets ignored. Having a standard process is very important, more so than getting the job done faster. Also having an outlined expectation for how it’s delivered is important as well. Documentation as Development Environment A useful trick that Cory uses, is using the documentation as the development environment. Anytime they are working on a new component, they start with a documentation site, making changes within the documentation and then it hot loading your changes live. This way your documentation is front of mind and keeps the documentation fall behind. Why React instead of the other frameworks? Cory says that he can sum up React in a single sentence. He says that your HTML sits right in the JavaScript. Which usually sounds bad to a large group of developers. He expects people to react negatively when he talks about it. What he has run into as a common problem, is people separating concerns by filetype and technology, but with React he seems the common problems in terms of components. Cory says that components are the future. Industries that have matured utilize components. For example car manufacturers or even electronic manufactures build things in modules and components. Things that are reusable should be encapsulated into a component instead of trying to hold it in our heads. This makes it so things look the same and reduces many mistakes. You can create components in different frameworks, but React co-mingles markup and javascript with something like JSX. You’re not writing HTML, you’re writing JSX that boils down to HTML. That one element is fundamentally what makes React easier to Cory. For the most part, React can be learned by JavaScript developers in less than a day because many of the things you need to do in React, is just basic JavaScript. Charles adds that components are a concept coming up in various frameworks and is becoming more popular. Picks Cory’s Cory’s React Courses on Pluralsight Essentialism the book Charles’ Get a Better Job Course Angular Remote Conf (now Ruby Dev Summit) React Podcast Kickstarter Links Cory’s Twitter

Where we discuss pratical guidelines for expanding your monitoring platform to cover the new and challenging world of Microservice (and Service Oriented Architecture) monitoring, with brief side trips into log tracing and fostering healthy culture. Comments for the episode are welcome - at the bottom of the show notes for the episode there is a Disqus setup, or you can email us at feedback@operations.fm Links for Episode 36: [Don’t Read Your Logs ] (https://medium.com/@chimeracoder/dont-read-your-logs-13586c790202) OpenTracing ZipKin Google Dapper Paper Standard Sensor Format Tenents Of Microservice Monitoring

Special guests Charles Krempeaux, Nathan Ladd, Adam Dymitruk, and Scott Bellware join host Drew Ogryzek for a discussion around monolithic software architecture versus microservices, what that means, and what the informed CEO should know when a team is considering tackling this type of software design shift.

Сугубо архитектурный и холиварный выпуск. Сначала - долгое обсуждение Service Oriented Architecture в iOS, ролей и контрактов сервисов. Потом - Clean Architecture от дядюшки Боба и Clean Swift как ее подмножество. Ну а на закуску - немного книг для прочтения и замечательных историй от ведущих про то, как они попали в мобильную разработку. Содержание: - 00:00 - Приветствие - 01:30 - Сервис-ориентированная архитектура - 03:13 - Слоистая архитектура - 06:15 - Что же такое сервис? - 15:00 - Проблемы неявных сервисов - 18:50 - Состояния в сервисе - 23:10 - Немного о core-компонентах - 25:00 - Священная война за сервисы - 31:40 - Проектирование сервиса госуслуг - 45:00 - Ограничения при проектировании компонентов - 59:00 - Сервисы против пришельцев фасадов - 01:02 - Кто, если не SOA? - 01:04 - Чистая архитектура дядюшки Боба - 01:10 - О “Clean swift architecture” либо хорошо, либо ничего - 01:25 - VIP cycle - 01:29 - Какая архитектура лучше или немного о ролях - 01:36 - Последние новости: - Apple купила Workflow - Reject приложения с ReactNative - iOS 10.3 (ответы пользователям, новая файловая система) - 01:50 - Ответы на вопросы - Как попали в iOS? - Какая литература повлияла? - 02:10 - Like, share, repost, join telegram channel Полезные ссылки: - Service Oriented Architecture https://www.youtube.com/watch?v=Eman1j06YsU - The Clean Architecture https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html - Get started with Clean Swift http://clean-swift.com - Apple покупает Workflow https://www.macstories.net/news/apple-acquires-workflow - Реджекты приложения на React Native https://github.com/facebook/react-native/issues/13011 - Xcode 8.3 генерирует большие бинарники http://www.openradar.me/31302382 - GTD in 15 minutes https://hamberg.no/gtd/

Service Oriented Architecture or SOA for short can mean different things. At the core, is the ability to send a message over a network to an isolated destination for a specific business purpose.

In this episode, Jacob and Michael talk about the recently released No Man's Sky, HTTP/2 middleware in Laravel, MailThief, and how Majestic Monoliths stack up against microservices.

Senior Technology & Business Executive with over 28 years of demonstrated leadership in building and leading high performance global teams. Proven strength in developing and executing Multi-year product strategy and transformation plans with business partnership, and translating conceptual business models and forecasts into specific IT growth strategies with sound execution Successful track record of delivering disruptive global business solutions and supporting mission-critical systems, enabling rapid customer, revenue, earnings, and market share growth. Provided significant value to business via continuous process improvements and operational excellence. Extensive financial industry experience building and supporting Banking, Credit Risk, Brokerage, 401K, Payroll, Trade Processing, Custody, Foreign Exchange, Fund Accounting, Core Client Operational systems. In-depth healthcare experience in H&W, Benefits Admin applications that enable Shop, Enroll, Manage and Exchange features Vast experience in leading Global Software Delivery Teams across all phases of SDLC in both Waterfall and Agile Methodologies, Architecture, Infrastructure, Networks, Supply/Demand Mgmt, CMMI, ITIL practices, SOA/ESB, Release and Config mgmt Systems, Service Oriented Architecture, Capacity Modeling, Quality Assurance and achieving aggressive financial objectives. Integrated four pillars of 3rd platform (Social, Mobile, Cloud and Big Data) into IT strategy Instrumental in setting up Large Global Data Centers and Co-locations and IT production and Offshore Operations in Captive & Vendor locations resulting in quicker product delivery, access to large talent pool, significant cost savings with 7x24 operation. Expert in optimizing and streamlining offshore sourcing model to improve the ROI and time to market capitalizing "follow-the-sun" strategy. Developed Balanced and Consumption Scorecards and tracked KPI & CSF Metrics to manage Performance, SLA and OLAs Seth Greene is a 6 Time Best Selling Author, Nationally Recognized Direct Response Marketing Expert, and the only back to back to back GKIC Dan Kennedy Marketer of the Year Nominee. To Get a FREE Copy of Seth’s new book Podcast Marketing Magic, and access to a Live Podcast Marketing Training Conference Call go to http://www.UltimateMarketingMagician.com Learn more about your ad choices. Visit megaphone.fm/adchoices

Sean and Derek discuss Monoliths, Service Oriented Architecture, and the new Adapter Specific Type Registry in Rails 5. Guest Sean Furret Haskell and tmux Upcase trails. Hashie Considered Harmful Adapter Specific Type Registry

Ben & Chris Hunt catch up on their latest conference talks, podcasts, and things accomplished on their recent coding retreat. Service Oriented Architecture at Square Solving the Rubik's Cube in 20 Seconds Trailmix Turing School Spanulate Podcast You Should Take a Codecation Codcation on reddit Healthy Hacker Podcast trailmix repo Chris on Twitter

Communications Service Providers CSP need to overcome the challenge of delivering innovative services at minimum cost while maintaining a positive customer experience. A series of best practices aimed at minimizing time-to-market through the use of requirements and feature management, Service Oriented Architecture and performance testing proves vital in the successful delivery of CSP services. Irv Badr, speaker.

Virginia Sharma, IBM Event Director for IMPACT, and Neil Johnson, Convention Sales Executive for Las Vegas Convention and Visitor's Authority, address concerns that Vegas and big conferences are impractical right now. The value of Vegas and the great resources at IMPACT are discussed, including SOA case studies, technical sessions, daily keynotes by IBM execs (and hosted by Billy Crystal), and more. Listen to the podcast for a special conference offer.

Transcript -- What is Service Oriented Architecture? Developers of Tesco Direct at IVIS and an SOA evangelist at IBM explain SOA's & their implementation.

What is Service Oriented Architecture? Developers of Tesco Direct at IVIS and an SOA evangelist at IBM explain SOA's & their implementation.

Transcript -- What is Service Oriented Architecture? Developers of Tesco Direct at IVIS and an SOA evangelist at IBM explain SOA's & their implementation.

What is Service Oriented Architecture? Developers of Tesco Direct at IVIS and an SOA evangelist at IBM explain SOA's & their implementation.

In this podcast, enterprise architecture expert Steven Kahn discusses some of the findings that went into the recently published, An Implementor’s Guide to Service Oriented Architecture – Getting it Right, produced by BearingPoint, Composite Software and[

Hayden Lindsey, IBM Distinguished Engineer and VP of the tools and compilers group, talks about the challenges of enterprise modernization going into detail about the five key types.

Danny Sabbah, GM of IBM Rational, spent a few minutes with Michael O'Connell talking about some of the things Rational is doing to interact with and listen more to customers, including an increased focus on clarity around business value.

Martin Nally, IBM Fellow and Rational Chief Technology Officer, talks with Michael O'Connell about RSDC conference announcements and their value proposition from a developer perspective, the open source opportunities around the Jazz platform, Jazz integration on the Internet, and the Telelogic acquisition.

In his keynote speech at the WebSphere IMPACT SOA technical conference in Las Vegas, Gary Cripps of Delaware Electric Cooperative talks about the huge transforming effect of SOA on his company's bottom line.

This is the second snippet of the SOA 2 double-episode. Eberhard and Markus continue the discussion with the issue of service reuse and a couple of development process issues. We also look at the duality between infrastructure development and application development in the context of an SOA. We then discuss the great spaghetti misunderstanding :-). We conclude this episode with a look at how to integrate BPM into the conceptual SOA framework we've built up to now, and we'll also briefly skim over a number of technologies related to SOA. Note that this episode, as well as the last one, is based on a set of slides; these can be downloaded from here. This episode covers slides 39 through 74.

This is the second snippet of the SOA 2 double-episode. Eberhard and Markus continue the discussion with the issue of service reuse and a couple of development process issues. We also look at the duality between infrastructure development and application development in the context of an SOA. We then discuss the great spaghetti misunderstanding :-). We conclude this episode with a look at how to integrate BPM into the conceptual SOA framework we've built up to now, and we'll also briefly skim over a number of technologies related to SOA. Note that this episode, as well as the last one, is based on a set of slides; these can be downloaded from here. This episode covers slides 39 through 74.

This is the second snippet of the SOA 2 double-episode. Eberhard and Markus continue the discussion with the issue of service reuse and a couple of development process issues. We also look at the duality between infrastructure development and application development in the context of an SOA. We then discuss the great spaghetti misunderstanding :-). We conclude this episode with a look at how to integrate BPM into the conceptual SOA framework we've built up to now, and we'll also briefly skim over a number of technologies related to SOA. Note that this episode, as well as the last one, is based on a set of slides; these can be downloaded from here. This episode covers slides 39 through 74.

In this, as well as in the next episode Eberhard and Markus continue their discussion about SOA (the episode got too long, so we had to split it into two ... SOA 2a and SOA 2b). In this episode, we talk about the various perspectives on SOA (CBD, EAI, BPM), about fundamental requirements towards an SOA, and we discuss the role of models in defining sustainable architectures. We also discuss how a programming model based on the described approach typically looks like. We then discuss a number of issues any large-scale SOA faces (and for which the SOA paradigm does not really provide an out-of-the-box solution: In this episode we discuss data type ownership and (weak) typing of data types.

In this, as well as in the next episode Eberhard and Markus continue their discussion about SOA (the episode got too long, so we had to split it into two ... SOA 2a and SOA 2b). In this episode, we talk about the various perspectives on SOA (CBD, EAI, BPM), about fundamental requirements towards an SOA, and we discuss the role of models in defining sustainable architectures. We also discuss how a programming model based on the described approach typically looks like. We then discuss a number of issues any large-scale SOA faces (and for which the SOA paradigm does not really provide an out-of-the-box solution: In this episode we discuss data type ownership and (weak) typing of data types.

In this, as well as in the next episode Eberhard and Markus continue their discussion about SOA (the episode got too long, so we had to split it into two ... SOA 2a and SOA 2b). In this episode, we talk about the various perspectives on SOA (CBD, EAI, BPM), about fundamental requirements towards an SOA, and we discuss the role of models in defining sustainable architectures. We also discuss how a programming model based on the described approach typically looks like. We then discuss a number of issues any large-scale SOA faces (and for which the SOA paradigm does not really provide an out-of-the-box solution: In this episode we discuss data type ownership and (weak) typing of data types.

SOA (Service Oriented Architecture) appears to be just another hype - after all we have been building distributed systems for quite a while now. But the real value of SOA is non-technical. In this episode Eberhard and Markus discuss the advantages and disadvantages, what SOA actually is and how it compares to other approaches that have been tried out before.

SOA (Service Oriented Architecture) appears to be just another hype - after all we have been building distributed systems for quite a while now. But the real value of SOA is non-technical. In this episode Eberhard and Markus discuss the advantages and disadvantages, what SOA actually is and how it compares to other approaches that have been tried out before.

SOA (Service Oriented Architecture) appears to be just another hype - after all we have been building distributed systems for quite a while now. But the real value of SOA is non-technical. In this episode Eberhard and Markus discuss the advantages and disadvantages, what SOA actually is and how it compares to other approaches that have been tried out before.

Getting on board Service Oriented Architecture (SOA) bandwagon may seem as simple as creating a few web services. But, there is more involved. Are all components of your IT organization ready for it?