The document discusses agile architecture and the role of a solution architect. It defines a solution architect as someone who understands the customer's problem, including constraints and domain knowledge, and uncovers and communicates a feasible solution. It emphasizes that discovering the solution is a team effort. The architect's responsibilities include understanding the problem, describing the problem context and domain model, describing the proposed solution, and simplifying and delivering the architecture and software.
This document discusses agile architecture, design, and delivery. It covers mapping features to user stories, managing themes, and providing examples of high level and low level design. Key points include: mapping each feature to multiple user stories but each user story to one feature; scheduling theme implementations; and showing the level of design detail from high level to low level design.
Event Driven Architecture (EDA) is presented as an alternative to Service Oriented Architecture (SOA). In EDA, business capabilities are defined which own parts of the system and communicate through shared communication channels using events, commands, and documents as messages. Examples are provided of a simple event and command message format. Key aspects of EDA include eventual consistency, idempotency, and ability to replay messages. The presentation concludes with discussing some advantages of EDA like improved scalability and isolation, and technologies used in one company's EDA infrastructure like RabbitMQ and Reactive Extensions.
This document discusses various integration and automation solutions for JDE Edwards systems, including:
- iBOLT, Magic Software's code-free integration platform that connects JD Edwards to other applications and platforms through visual workflows.
- Pre-built iBOLT connectors and components for JD Edwards that support 50+ adapters, services and methods.
- Examples of iBOLT integrations including SharePoint and Dynamics CRM.
- The company's functional expertise in various JD Edwards modules like finance, supply chain, manufacturing and service management.
Impact 2014 1147 - Bridging Business Process Management and Integration use c...Brian Petrini
IBM Integration Bus makes it easy to integrate connectivity logic with business processes. This session explains everything teams need to know about using IBM Integration Bus in conjunction with IBM Business Process Manager Standard and Advanced. Presenters also provide insight into how this easy-to-use technology will evolve.
- Areon Consulting is an established company with over 75 specialists that has experience implementing Siebel CRM and BI projects for banking, insurance, and telecommunications companies.
- They offer Siebel implementation and integration services along with business consulting, development, and BI analysis. They also provide training and have partnerships with technology vendors.
- For potential partners, Areon offers competitive rates, flexible pricing models, proven project experience, and the ability to handle any implementation challenges due to their expertise in Siebel projects.
InterConnect 2017 HBP-2884-IBM BPM upgrade and migration made easyBrian Petrini
Upgrading to the latest version of IBM BPM has never been easier. Ever since the release of IBM BPM 8500 in 2013, customers has been able to move to the latest release with an in-place upgrade without the need for data migration. This session will discuss the top practices in planning a painless upgrade to the latest BPM continuous release version?whether you are running BPM 85x or an older version. We will also discuss the options available if you want to move your BPM program to the cloud. In addition, we will also discuss ways to design your applications to ensure an easy upgrade every time.
This presentation begins with a short overview of BPM Suite, and how it was used to meet real life challenges in different vertical markets. We conclude with a preview of what's new in jBPM version 6 and what's on the horizon for JBoss middleware technologies.
Impact 2012 1640 - BPM Design considerations when optimizing business process...Brian Petrini
Whilst it is not always possible to remove and automate human tasks in a process, if it can be done, it often leads to the most dramatic optimization, leading to fully straight through processing. The challenge is that if straight through processing is the goal, we may need to design the process differently from the beginning, with automation in mind. This lecture uses tried and tested techniques for assessing processes to establish whether they are likely to be able to evolve to full automation, and recommends design patterns to be used to simplify the progression from manual to decision supported to completely automated.
This document discusses agile architecture, design, and delivery. It covers mapping features to user stories, managing themes, and providing examples of high level and low level design. Key points include: mapping each feature to multiple user stories but each user story to one feature; scheduling theme implementations; and showing the level of design detail from high level to low level design.
Event Driven Architecture (EDA) is presented as an alternative to Service Oriented Architecture (SOA). In EDA, business capabilities are defined which own parts of the system and communicate through shared communication channels using events, commands, and documents as messages. Examples are provided of a simple event and command message format. Key aspects of EDA include eventual consistency, idempotency, and ability to replay messages. The presentation concludes with discussing some advantages of EDA like improved scalability and isolation, and technologies used in one company's EDA infrastructure like RabbitMQ and Reactive Extensions.
This document discusses various integration and automation solutions for JDE Edwards systems, including:
- iBOLT, Magic Software's code-free integration platform that connects JD Edwards to other applications and platforms through visual workflows.
- Pre-built iBOLT connectors and components for JD Edwards that support 50+ adapters, services and methods.
- Examples of iBOLT integrations including SharePoint and Dynamics CRM.
- The company's functional expertise in various JD Edwards modules like finance, supply chain, manufacturing and service management.
Impact 2014 1147 - Bridging Business Process Management and Integration use c...Brian Petrini
IBM Integration Bus makes it easy to integrate connectivity logic with business processes. This session explains everything teams need to know about using IBM Integration Bus in conjunction with IBM Business Process Manager Standard and Advanced. Presenters also provide insight into how this easy-to-use technology will evolve.
- Areon Consulting is an established company with over 75 specialists that has experience implementing Siebel CRM and BI projects for banking, insurance, and telecommunications companies.
- They offer Siebel implementation and integration services along with business consulting, development, and BI analysis. They also provide training and have partnerships with technology vendors.
- For potential partners, Areon offers competitive rates, flexible pricing models, proven project experience, and the ability to handle any implementation challenges due to their expertise in Siebel projects.
InterConnect 2017 HBP-2884-IBM BPM upgrade and migration made easyBrian Petrini
Upgrading to the latest version of IBM BPM has never been easier. Ever since the release of IBM BPM 8500 in 2013, customers has been able to move to the latest release with an in-place upgrade without the need for data migration. This session will discuss the top practices in planning a painless upgrade to the latest BPM continuous release version?whether you are running BPM 85x or an older version. We will also discuss the options available if you want to move your BPM program to the cloud. In addition, we will also discuss ways to design your applications to ensure an easy upgrade every time.
This presentation begins with a short overview of BPM Suite, and how it was used to meet real life challenges in different vertical markets. We conclude with a preview of what's new in jBPM version 6 and what's on the horizon for JBoss middleware technologies.
Impact 2012 1640 - BPM Design considerations when optimizing business process...Brian Petrini
Whilst it is not always possible to remove and automate human tasks in a process, if it can be done, it often leads to the most dramatic optimization, leading to fully straight through processing. The challenge is that if straight through processing is the goal, we may need to design the process differently from the beginning, with automation in mind. This lecture uses tried and tested techniques for assessing processes to establish whether they are likely to be able to evolve to full automation, and recommends design patterns to be used to simplify the progression from manual to decision supported to completely automated.
The tension between agile and architecturePeter Hendriks
Agile and architecture are often considered cats and dogs. Many "classic" software architecture methods are considered an enemy of agile principles: often describing heavyweight, upfront documents and decisions, and a hierarchy with architects wielding all technical decision power and responsibility.
Although there are some new "agile architecture" concepts out there, these typically only address small parts of the problem and often require significant skill to practice correctly. There is even the notion that architecture is not needed anymore when applying agile practices.
But what is "architecture" anyway? This infodeck gives an overview on architecture as a concept, a process and a role. It is delivered as stand-alone slides, and should be useful for anyone involved in building software systems.
This document discusses principles of agile architecture, including that teams should code and design systems, build the simplest architecture possible, and test what they build. It also discusses building an "architectural runway" by determining an initial component-based architecture and prototyping if needed. Extending the runway involves identifying future needs and evaluating them. The document cautions against the myth that up-front architecture is bad, stating that some initial architectural decisions are needed.
The document discusses how to design teams for modern software systems. It covers Conway's Law which states that a product's architecture will mirror the structure of the organization that developed it. It also discusses cognitive load on teams and how stress can reduce team performance. Real-world team topologies are presented, such as component teams, platform teams, and product teams. Guidelines are provided for configuring teams, including matching team responsibilities to their cognitive load. The document advocates evolving different team topologies over time based on factors like the team's purpose and context.
Agile Architecture and Modeling - Where are we TodayGary Pedretti
Ideals, Misinterpretations, Backlash, a New Hope - A talk on where we've been and where we're going with agile application architecture. As presented at Toronto Agile and Software 2014 on 11/10/2014.
Does Agile Enterprise Architecture = Agile + Enterprise Architecture?Jason Bloomberg
Does Agile EA Equal Agile Plus EA?
Confusion over the word “agile” is actually one of the challenges with Enterprise Architecture (EA) today. So, what does "agile" -- or in some quarters, "Agile" -- mean today, and how do we apply Agile to architecture? Most people use the phrase "Agile Architecture" to refer to software architecture appropriate for Agile software development projects -- not EA at all.
Nevertheless, there is a growing Agile EA movement that extends the core principles of the Agile manifesto to EA more broadly. This approach deemphasizes the role of frameworks and other artifacts, and instead treats the enterprise as a complex adaptive system.
Agile EA thus leverages complex systems theory, including the role of emergent properties, to rethink how organizations innovate and otherwise deal with change within the context of market and regulatory constraints.
Attendees of this session will:
* Gain clear differentiators between Agile software architecture and Agile EA
* Understand the role of complex systems theory to the practice of Agile EA
* Learn how Bloomberg Agile Architecture(tm) can support organizations' agility requirements in the future
This document discusses applying agile principles and practices to TOGAF architecture projects. It outlines the goals of mapping agile approaches to the TOGAF Architecture Development Method (ADM). Key aspects covered include mapping agile values, principles, practices and roles to the TOGAF ADM phases. Specific techniques like story cards, planning boards and retrospectives are described. The workshop aims to provide guidance on an agile enterprise architecture approach and get feedback to inform future standards.
Adam boczek 2015 agile architecture in 10 steps v1.0iasaglobal
This document outlines a 10 step process for developing agile architecture. It begins by discussing how innovation drives business and the need for supporting IT architecture. The 10 steps include: identifying business domains; creating a business entity model; defining a ubiquitous language; defining an initial process architecture; modeling core business processes; defining vertical requirements; defining bounded contexts; creating a BD/QA relevancy matrix; defining solution strategies; and defining building blocks. The goal is to develop an architecture that reduces risks, supports business agility, and focuses on simplicity through transparency, abstractions and partitioning.
Presentation by Davor Cengija from Agile Lean Europe 2014 in Krakow, Poland. http://ale2014.alenetwork.eu/
See how agile and lean principles can help Enterprise Architecture achieve its goals.
Microservices: Architecture for Agile Software DevelopmentEberhard Wolff
This document discusses microservices architecture and how it enables agility. It defines microservices as small, independent units that can be developed and deployed autonomously. The document argues that microservices align with the principles of the Agile Manifesto by allowing teams to work independently, facilitating continuous delivery, and making the architecture adaptable to change. Some benefits outlined are improved scalability, maintainability, and ability to replace services easily. The conclusion is that by structuring an organization and software architecture around microservices, greater agility can be achieved compared to a monolithic architecture.
Why We Need Architects (and Architecture) on Agile ProjectsRebecca Wirfs-Brock
This is an updated version of this talk which I will present at Agile 2013.
The rhythm of agile software development is to always be working on the next known, small batch of work. Is there a place for software architecture in this style of development? Some people think that software architecture should simply emerge and doesn’t require ongoing attention. But it isn’t always prudent to let the software architecture emerge at the speed of the next iteration. Complex software systems have lots of moving parts, dependencies, challenges, and unknowns. Counting on the software architecture to spontaneously emerge without any planning or architectural investigation is at best risky.
So how should architecting be done on agile projects? It varies from project to project. But there are effective techniques for incorporating architectural activities into agile projects. This talk explains how architecture can be done on agile projects and what an agile architect does.
The document discusses agile architecture and solution design, outlining how an architect should understand the customer problem, uncover and communicate a feasible solution through describing the architecture, simplifying it based on constraints, and delivering the software solution through iterative development and demos using a technique called "rainbow planning".
These are my slides from the Bare-Bones Software Architecture course at XP Days Ukraine 2012. The workshop outlines a quick workshop-oriented process for initiating software projects
Domain Driven Design Big Picture Strategic PatternsMark Windholtz
The document discusses Domain-Driven Design (DDD), an approach to software development for complex problems. It provides an overview of DDD and strategic patterns for organizing large projects with multiple teams, such as defining bounded contexts and context maps. Context maps describe the relationships between models, including shared kernels, customer/supplier, and conformist relationships. The document emphasizes defining a ubiquitous language within each context and mapping contexts to understand integration strategies at a large scale.
Implementing Domain-Driven Design study group - ch. 5 entitiesHenry Tong
Entities such as Users and Tenants were discovered from the requirements. Users are uniquely identified by their username and password, while Tenants have a unique UUID identifier. Essential behaviors for these entities include authentication, registration of Users by Tenants, and activation/deactivation of Tenants. When designing the entities, considerations include using value objects for identifiers, defining meaningful behaviors rather than just boolean flags, and separating authentication into a separate service.
This document discusses code generation in .NET. It begins by outlining some common problems developers face when dealing with large amounts of repetitive code. It then discusses various approaches to solving this problem, including hand coding everything, fully generic design, and using a combination of tools including code generation. The rest of the document discusses specific code generation tools for .NET like StringBuilder, CodeSnippets, XSLT, Reflection.Emit, EnvDTE, CodeDom, and T4. It also discusses pros and cons of each approach and provides examples of using code generation in different real world scenarios.
This document discusses Behavior Driven Development (BDD) using the Ruby programming language. It provides an overview of test-driven development (TDD), then defines BDD as building upon TDD by formalizing good TDD habits like working outside-in from business goals. Gherkin is introduced as the language used for writing Cucumber features, using examples to clarify requirements. Cucumber is a tool for running automated acceptance tests written in a BDD style using Gherkin. It also discusses using Capybara to access and interact with web pages in tests.
This document provides an overview of domain-driven design (DDD) patterns and concepts. It discusses when DDD is applicable, specifically for complex systems. The core concepts of DDD building blocks are then summarized, including layered architecture, entities, value objects, aggregates, factories, repositories, services, and domain events. Examples are provided for some of the concepts. Meeting topics are listed that will cover strategic patterns, tactical patterns, communication tips, and code examples related to DDD.
Communication tool & Environment for Remote WorkerShotaro Sakamaki
Shotaro Sakamaki is a front-end engineer at PixelGrid.Inc, a company that develops JavaScript applications. He discusses the communication tools and development environment used by PixelGrid's remote workers. Key tools mentioned include Slack for chat, esa.io for documentation sharing, GitHub for source control, and ZenHub as a GitHub extension. Costs for these paid services range from $3.99 to $6.67 per user per month. While costs may seem high, the speaker argues they replace expenses from maintaining multiple free tools and reduce invisible maintenance costs.
How and Why you can and should Participate in Open Source Projects (AMIS, Sof...Lucas Jellema
For a long time I have been reluctant to actively contribute to an open source project. I thought it would be rather complicated and demanding – and that I didn't have the knowledge or skills for it or at the very least that they (the project team) weren't waiting for me.
In December 2021, I decided to have a serious input into the Dapr.io project – and now finally to determine how it works and whether it is really that complicated. In this session I want to tell you about my experiences. How Fork, Clone, Branch, Push (and PR) is the rhythm of contributing to an open source project and how you do that (these are all Git actions against GitHub repositories). How to learn how such a project functions and how to connect to it; which tools are needed, which communication channels are used. I tell how the standards of the project – largely automatically enforced – help me to become a better software engineer, with an eye for readability and testability of the code.
How the review process is quite exciting once you have offered your contribution. And how the final "merge to master" of my contribution and then the actual release (Dapr 1.6 contains my first contribution) are nice milestones.
I hope to motivate participants in this session to also take the step yourself and contribute to an open source project in the form of issues or samples, documentation or code. It's valuable to the community and the specific project and I think it's definitely a valuable experience for the "contributer". I looked up to it and now that I've done it gives me confidence – and it tastes like more (I could still use some help with the work on Dapr.io, by the way).
The tension between agile and architecturePeter Hendriks
Agile and architecture are often considered cats and dogs. Many "classic" software architecture methods are considered an enemy of agile principles: often describing heavyweight, upfront documents and decisions, and a hierarchy with architects wielding all technical decision power and responsibility.
Although there are some new "agile architecture" concepts out there, these typically only address small parts of the problem and often require significant skill to practice correctly. There is even the notion that architecture is not needed anymore when applying agile practices.
But what is "architecture" anyway? This infodeck gives an overview on architecture as a concept, a process and a role. It is delivered as stand-alone slides, and should be useful for anyone involved in building software systems.
This document discusses principles of agile architecture, including that teams should code and design systems, build the simplest architecture possible, and test what they build. It also discusses building an "architectural runway" by determining an initial component-based architecture and prototyping if needed. Extending the runway involves identifying future needs and evaluating them. The document cautions against the myth that up-front architecture is bad, stating that some initial architectural decisions are needed.
The document discusses how to design teams for modern software systems. It covers Conway's Law which states that a product's architecture will mirror the structure of the organization that developed it. It also discusses cognitive load on teams and how stress can reduce team performance. Real-world team topologies are presented, such as component teams, platform teams, and product teams. Guidelines are provided for configuring teams, including matching team responsibilities to their cognitive load. The document advocates evolving different team topologies over time based on factors like the team's purpose and context.
Agile Architecture and Modeling - Where are we TodayGary Pedretti
Ideals, Misinterpretations, Backlash, a New Hope - A talk on where we've been and where we're going with agile application architecture. As presented at Toronto Agile and Software 2014 on 11/10/2014.
Does Agile Enterprise Architecture = Agile + Enterprise Architecture?Jason Bloomberg
Does Agile EA Equal Agile Plus EA?
Confusion over the word “agile” is actually one of the challenges with Enterprise Architecture (EA) today. So, what does "agile" -- or in some quarters, "Agile" -- mean today, and how do we apply Agile to architecture? Most people use the phrase "Agile Architecture" to refer to software architecture appropriate for Agile software development projects -- not EA at all.
Nevertheless, there is a growing Agile EA movement that extends the core principles of the Agile manifesto to EA more broadly. This approach deemphasizes the role of frameworks and other artifacts, and instead treats the enterprise as a complex adaptive system.
Agile EA thus leverages complex systems theory, including the role of emergent properties, to rethink how organizations innovate and otherwise deal with change within the context of market and regulatory constraints.
Attendees of this session will:
* Gain clear differentiators between Agile software architecture and Agile EA
* Understand the role of complex systems theory to the practice of Agile EA
* Learn how Bloomberg Agile Architecture(tm) can support organizations' agility requirements in the future
This document discusses applying agile principles and practices to TOGAF architecture projects. It outlines the goals of mapping agile approaches to the TOGAF Architecture Development Method (ADM). Key aspects covered include mapping agile values, principles, practices and roles to the TOGAF ADM phases. Specific techniques like story cards, planning boards and retrospectives are described. The workshop aims to provide guidance on an agile enterprise architecture approach and get feedback to inform future standards.
Adam boczek 2015 agile architecture in 10 steps v1.0iasaglobal
This document outlines a 10 step process for developing agile architecture. It begins by discussing how innovation drives business and the need for supporting IT architecture. The 10 steps include: identifying business domains; creating a business entity model; defining a ubiquitous language; defining an initial process architecture; modeling core business processes; defining vertical requirements; defining bounded contexts; creating a BD/QA relevancy matrix; defining solution strategies; and defining building blocks. The goal is to develop an architecture that reduces risks, supports business agility, and focuses on simplicity through transparency, abstractions and partitioning.
Presentation by Davor Cengija from Agile Lean Europe 2014 in Krakow, Poland. http://ale2014.alenetwork.eu/
See how agile and lean principles can help Enterprise Architecture achieve its goals.
Microservices: Architecture for Agile Software DevelopmentEberhard Wolff
This document discusses microservices architecture and how it enables agility. It defines microservices as small, independent units that can be developed and deployed autonomously. The document argues that microservices align with the principles of the Agile Manifesto by allowing teams to work independently, facilitating continuous delivery, and making the architecture adaptable to change. Some benefits outlined are improved scalability, maintainability, and ability to replace services easily. The conclusion is that by structuring an organization and software architecture around microservices, greater agility can be achieved compared to a monolithic architecture.
Why We Need Architects (and Architecture) on Agile ProjectsRebecca Wirfs-Brock
This is an updated version of this talk which I will present at Agile 2013.
The rhythm of agile software development is to always be working on the next known, small batch of work. Is there a place for software architecture in this style of development? Some people think that software architecture should simply emerge and doesn’t require ongoing attention. But it isn’t always prudent to let the software architecture emerge at the speed of the next iteration. Complex software systems have lots of moving parts, dependencies, challenges, and unknowns. Counting on the software architecture to spontaneously emerge without any planning or architectural investigation is at best risky.
So how should architecting be done on agile projects? It varies from project to project. But there are effective techniques for incorporating architectural activities into agile projects. This talk explains how architecture can be done on agile projects and what an agile architect does.
The document discusses agile architecture and solution design, outlining how an architect should understand the customer problem, uncover and communicate a feasible solution through describing the architecture, simplifying it based on constraints, and delivering the software solution through iterative development and demos using a technique called "rainbow planning".
These are my slides from the Bare-Bones Software Architecture course at XP Days Ukraine 2012. The workshop outlines a quick workshop-oriented process for initiating software projects
Domain Driven Design Big Picture Strategic PatternsMark Windholtz
The document discusses Domain-Driven Design (DDD), an approach to software development for complex problems. It provides an overview of DDD and strategic patterns for organizing large projects with multiple teams, such as defining bounded contexts and context maps. Context maps describe the relationships between models, including shared kernels, customer/supplier, and conformist relationships. The document emphasizes defining a ubiquitous language within each context and mapping contexts to understand integration strategies at a large scale.
Implementing Domain-Driven Design study group - ch. 5 entitiesHenry Tong
Entities such as Users and Tenants were discovered from the requirements. Users are uniquely identified by their username and password, while Tenants have a unique UUID identifier. Essential behaviors for these entities include authentication, registration of Users by Tenants, and activation/deactivation of Tenants. When designing the entities, considerations include using value objects for identifiers, defining meaningful behaviors rather than just boolean flags, and separating authentication into a separate service.
This document discusses code generation in .NET. It begins by outlining some common problems developers face when dealing with large amounts of repetitive code. It then discusses various approaches to solving this problem, including hand coding everything, fully generic design, and using a combination of tools including code generation. The rest of the document discusses specific code generation tools for .NET like StringBuilder, CodeSnippets, XSLT, Reflection.Emit, EnvDTE, CodeDom, and T4. It also discusses pros and cons of each approach and provides examples of using code generation in different real world scenarios.
This document discusses Behavior Driven Development (BDD) using the Ruby programming language. It provides an overview of test-driven development (TDD), then defines BDD as building upon TDD by formalizing good TDD habits like working outside-in from business goals. Gherkin is introduced as the language used for writing Cucumber features, using examples to clarify requirements. Cucumber is a tool for running automated acceptance tests written in a BDD style using Gherkin. It also discusses using Capybara to access and interact with web pages in tests.
This document provides an overview of domain-driven design (DDD) patterns and concepts. It discusses when DDD is applicable, specifically for complex systems. The core concepts of DDD building blocks are then summarized, including layered architecture, entities, value objects, aggregates, factories, repositories, services, and domain events. Examples are provided for some of the concepts. Meeting topics are listed that will cover strategic patterns, tactical patterns, communication tips, and code examples related to DDD.
Communication tool & Environment for Remote WorkerShotaro Sakamaki
Shotaro Sakamaki is a front-end engineer at PixelGrid.Inc, a company that develops JavaScript applications. He discusses the communication tools and development environment used by PixelGrid's remote workers. Key tools mentioned include Slack for chat, esa.io for documentation sharing, GitHub for source control, and ZenHub as a GitHub extension. Costs for these paid services range from $3.99 to $6.67 per user per month. While costs may seem high, the speaker argues they replace expenses from maintaining multiple free tools and reduce invisible maintenance costs.
How and Why you can and should Participate in Open Source Projects (AMIS, Sof...Lucas Jellema
For a long time I have been reluctant to actively contribute to an open source project. I thought it would be rather complicated and demanding – and that I didn't have the knowledge or skills for it or at the very least that they (the project team) weren't waiting for me.
In December 2021, I decided to have a serious input into the Dapr.io project – and now finally to determine how it works and whether it is really that complicated. In this session I want to tell you about my experiences. How Fork, Clone, Branch, Push (and PR) is the rhythm of contributing to an open source project and how you do that (these are all Git actions against GitHub repositories). How to learn how such a project functions and how to connect to it; which tools are needed, which communication channels are used. I tell how the standards of the project – largely automatically enforced – help me to become a better software engineer, with an eye for readability and testability of the code.
How the review process is quite exciting once you have offered your contribution. And how the final "merge to master" of my contribution and then the actual release (Dapr 1.6 contains my first contribution) are nice milestones.
I hope to motivate participants in this session to also take the step yourself and contribute to an open source project in the form of issues or samples, documentation or code. It's valuable to the community and the specific project and I think it's definitely a valuable experience for the "contributer". I looked up to it and now that I've done it gives me confidence – and it tastes like more (I could still use some help with the work on Dapr.io, by the way).
This document summarizes a presentation about using Ruby in an office setting. It discusses four case studies: [1] Applying the issue tracker Redmine to various projects beyond software development, [2] Using GitLab to allow every team member to easily create repositories for Redmine projects, [3] Using the Axlsx gem to generate Excel files for communicating project data with clients, and [4] Using the Sinatra web framework to easily create scripts for tasks like generating screenshots from a web repository. The document concludes by asking about what makes Ruby programming enjoyable.
A quick overview of API Design Workflow, describing my views on waterfall API design approach, why we've built Apiary a certain way and random notes from the API industry
What is cool with Domino V10, Proton and Node.JS, and why would I use it in ...Heiko Voigt
This document discusses using Node.js, React, and Express with Domino V10. It provides an overview of a demo that uses these technologies to build a survey application with a real-time dashboard. The demo includes a Notes/iPad app for surveys, a React frontend, a Node.js/Express REST API, and a Node.js/Socket.io real-time backend. It discusses the benefits of this approach, including scalability, flexibility, and reusability. It also provides recommendations for tooling and resources for learning more.
Session at tcworld 2016. Organized by Kristen James Eberlein (Eberlein Consulting LLC); other participants were Joe Gollner (Gnostyx), George Bina (SyncroSoft), Jean-François Ameye (IXIASOFT), and Eliot Kimber (Contrext).
Prashant technical practices-tdd for xebia eventXebia India
Theme: Agile Technical Practices
Epic: TDD implementation
Stories:
Context of TDD
What is TDD
Response of Developers to TDD implementation
Practices complimenting TDD
Success with TDD
The first day slides of the Domain Driven Design course that I imparted on Schibsted Spain.
They talk about technical debt, domain modeling, model driven design and SOLID principles.
The document discusses moving from applications to the enterprise architecture. It begins with an introduction to the speaker and their experience. It then outlines a plan to discuss the history of software development, the software portfolio, breaking down silos, and layering the enterprise. For each section, it provides details on the concepts and examples to illustrate how to analyze applications and integrate them at the enterprise level to avoid silos. The goal is to show how to evolve individual applications into an integrated enterprise architecture.
This document provides guidance on designing microservices using the Go programming language. It begins with an introduction to Go's core concepts like packages, functions, methods, structs, interfaces, errors, goroutines, and what Go does not include. It then discusses when Go is well-suited and not well-suited through examples. The document concludes with tips for designing Go microservices, including leveraging existing frameworks, using interfaces, ORM for entities, centralizing configurations, and making errors meaningful. The overall message is to understand where Go works best and mix technologies as needed while avoiding unnecessary complexity.
Five favorite features of native apps that you might not realize you can do on a web application.
Supporting slides for my presentation at JavaBin June 11, 2015.
Can you go faster with less weight? In 45 minutes, I build a web server with an address book with tests firsts and no frameworks. What can you do if you really understand what's going on?
Good programming is not something that can be explained, it has to be experienced. In this talk, you will see pair programming and test-driven development in action. The talk will involve the audience and draw on your insight to show how programming can be more fun! If you want to understand how serious test-driven development looks, this talk is for you.
The talk is based around a demonstration and interactive audience discussion, so the slides will not capture much of the content.
The document summarizes an "Extreme Programming" talk given by Johannes Brodwall. The talk demonstrates test-driven development and pair programming. It discusses the benefits of these practices, such as producing higher quality code through simplicity, communication, and feedback. It encourages programmers to practice deliberately, both at work and at home, in order to continuously improve. The conclusion emphasizes freeing the mind and practicing programming as an art.
In this talk, we will go through a practical approach for remote pair programming adopted for high-latency situations. We will demonstrate remote pair programming with a live example and we will discuss the advantages and usages of the approach.
The document summarizes an "Extreme Programming" talk given by Johannes Brodwall. The talk introduces concepts like test-driven development (TDD), pair programming, and refactoring. A demonstration of pair programming on a coding kata is shown. The key points emphasized are that practicing TDD in small iterative steps, pairing with others, and continuously refactoring code can help programmers improve quality and think in a more deliberate, mindful way about their work. The overall message is that becoming a better programmer requires freeing one's mind and practicing programming as an art.
The document describes Johannes Brodwall's philosophy of "bare-knuckle web development" which advocates for lightweight frameworks, test-driven development, and avoiding unnecessary complexity. It then demonstrates this approach through building a simple phonebook web application in Java using only the bare essentials like servlets and XML parsing. Finally, it discusses further directions this approach could be taken, such as building applications for the Norwegian agricultural authority and power grid operator.
This document summarizes the agenda for a coding dojo event, which includes demonstrations of test-driven development and pair programming, followed by several coding kata exercises involving topics like prime factorization, minesweeper, Yahtzee, and converting numbers to Roman numerals. Participants will work individually and in pairs on test cases for these kata. There will also be two rounds of an "extreme startup" code competition. Retrospectives are scheduled after each activity to discuss lessons learned.
1) The document discusses principles of agile programming such as pair programming, test-driven development, and refactoring.
2) It describes a demonstration of test-driven development using a minesweeper game, highlighting how tests are written first and then code is produced to pass those tests.
3) The document emphasizes that practicing these agile techniques through deliberate practice of coding katas can help programmers improve their skills and "think better" above just the code level. Regular practice is encouraged at meetups like the Prague Coding Dojo.
The document discusses using agile principles and contracts for large government IT projects. It proposes that "time and material" contracts create the most satisfaction, as they allow for collaboration over negotiation. However, large tax-funded projects require more structure. The document examines how the Norwegian PS2000 standard combines agile practices with target pricing models. It provides examples of projects that successfully blended agile and contracts, as well as areas that caused issues. Finally, it envisions an alternative approach using competitive bidding on small, independent teams with unit pricing for user stories. This could encourage collaboration over lengthy negotiations and change orders.
Påstand: Årsaken til at dagens kontraktregime trekker i retning fossefallsprosjekter uten rom for læring er at kontraktene forutsetter at prisen for prosjektet er låst ved oppstart. For å angi pris, må det beskrives hva prisen gjelder.
Forslag til løsning: Kontrakten kan regulerer prisen per feature på produktkøen. Kunden har da muligheten til å endre produktkøen etter behov uten at dette blir en kontraktsmessig endring.
Jeg kaller dette Stykkpriskontrakt.
For å fastsette initiell stykkpris og for å understøtte konkurranse mellom leverandører foreslår jeg videre at et utvalg av leverandører inviteres til å levere funksjonalitet i en konkurransefase. Den beste får kontrakten og erfaringsdata fra konkurransefasen brukes som input til å bestemme initiell stykkpris.
Jeg kaller dette prestasjonsbasert konkurranse.
Dette er løse ideer og har aldri vært prøvd.
This document discusses using agile principles and practices in government contracting. It proposes that customer collaboration over contract negotiation better serves agile values. It describes how some Norwegian government projects have incorporated elements of agile, like sprints and product backlogs, while still using traditional cost-plus contracts. The document suggests a model of competitive bidding between suppliers to deliver user stories could further foster collaboration over negotiation. Overall, it argues that Norway provides a starting point but there is still room for improvement in aligning contracts with agile principles.
This document summarizes an Agile programming experience day in Ukraine. The goal is for attendees to have fun programming now and to think better by practicing their skills. The agenda includes a description of a minesweeper coding kata demonstration featuring pair programming. Attendees are encouraged to observe how the pair interacts, designs the code, and progresses through testing. The benefits of practices like test-driven development, pairing, and refactoring are discussed. The conclusion encourages practicing programming skills at work, with coding dojos, and by freeing the mind.
4. A solution architect is
someone who understands
the problem of the customer
and uncovers and
communicates
a feasible solution
5. A solution architect is someone who
understands the customer’s
problem (including
contraints, context, domain knowledge)
and uncovers (though a team effort)
and communicates (with credibility) a
feasible solution (primarily, but not
exclusively technical)
6. Uncover problem
vision, stakeholders, usage flow
Describe problem
context and domain model
Describe solution
deployment, implementation model
Simplify architecture
feature oriented structure
Deliver software
rainbow plans
12. For some stakeholder
Who has a goal
The Colombo Agile Meetup
Is a type of activity
Which gives a capability.
Unlike most relevant alternative
This has a distinguishing attribute.
13. For anyone interested in agile methods
Who ________________
The Colombo Agile Meetup
Is a _________________
Which ________________.
Unlike ______________________
This _______________________.
16. For Agile practitioners
Who need to expand on their experience and network
The Smidig conference
Is a networking event
Which connects you with other Agile practitioners.
Unlike traditional conferences
This presents the experience of many people through
lightning talks.
17. For Conference organizers
Who want to organize a good conference
The Smidig conference app
Is a web application
Which eliminates unnecessary work.
Unlike commercial conference apps
This is optimized for the large number of talks
we have and allows us to make changes fast.
20. Speaker Attendee Organizer
Description Description Description
• Experienced • Knows about agile • Volunteer
• New speaker • Works in project • Works in evenings
• Passionate • Norwegian • Has network
Duties Duties Duties
• Register talk • Pay for conference • Select talks
• Upload slide • Get approval to go • Follow up
• Give talk payments
Values Values
Values • Easy selection process
• Constructive
• Easy registration • Good information
feedback on talk overview
• Easy CfP • Never lose a participant
• Fast answer • Financial transparency
23. Attendance
1. Agile project practitioner wants to learn
2. Attendee goes to Smidig website
3. Attendee registers
4. Attendee pays
5. Attendee receives confirmation mail
6. Organizer can see the registration
7. Organizer sends reminder email to attendee
to come
8. Organizer prints badges for attendees
9. Attendee shows up at Smidig and has an
excellent time
24.
25. Speaker
1. Agile experts wants to share knowledge
2. Potential speaker goes to Smidig website
3. Potential speaker registers personal info
4. Potential speaker registers talk
5. Potential speaker receives registration confirmation
email
6. Organizer sees registered talk and can market
speaking opportunities
7. Organizer accepts talk for confence
8. Speaker receives acceptance email
– Alternative: Speaker withdraws talk – organizer updates
the talk and selects another
9. Organizer prints badges for speakers
10. Speaker shows up at Smidig and gives talk
31. User
• Name Registration
• Email • Ticket type
• Price
• Company • Paid amount
• Phone • Paypal ref
• Password • Payment date
• Invoice address [optional]
• Accepts email?
*
Comment *
• Title Speaker
• Text
• Created date *
* Talk Period
• Title
• Description • Stage
• Tags[] • Title
• Slide file • Time of day
• Status : • Day
{pending, accept, rejec
t}
• Email_sent
• Position
33. Browser Smidig2012.no Paypal.com
1. POST /users
Save user info
2. Redirect to paypal
with return_url and notify_url
3. Perform payment
4. POST /payment_notifications
Update user
info
5. Redirect to return_url
5. GET /user/<id>
Show user info
86. Usage flow
1. Something happens in the real world
2. The event is communicated to the system
3. The system does something
4. Someone does something with the system
5. …
6. …
7. …
8. …
9. …
10. Some goal is achieved
90. Usage flow: frugalflights.com
1. A customer wants cheap vacations
2. The customer signs up for daily or weekly notifications of special
flight offers
3. Periodically the System checks which customers should get
notifications
4. The System checks for offers that matches the customer’s travel
preference by looking up flights with the travel provider system
5. The System notifies customer of any matching offers via SMS
• Variation: The System notifies customer of any matching offers via
email
6. The customer accepts the offer via SMS
1. Variation: The customer accepts the offer on the system website
7. The System books the tickets on behalf of the customer
8. The system confirms the booking by sending an SMS to the
customer
9. The customer can at any point see their active offers and accepted
offers on the system website
10. The customer enjoys a cheap vacation!
92. Usage flow: frugalflights.com
1. A customer wants cheap vacations
2. The customer signs up for daily or weekly notifications of special
flight offers
3. Periodically the System checks which customers should get
notifications
4. The System checks for offers that matches the customer’s travel
preference by looking up flights with the travel provider system
5. The System notifies customer of any matching offers via SMS
• Variation: The System notifies customer of any matching offers via
email
6. The customer accepts the offer via SMS
1. Variation: The customer accepts the offer on the system website
7. The System books the tickets on behalf of the customer
8. The system confirms the booking by sending an SMS to the
customer
9. The customer can at any point see their active offers and accepted
offers on the system website
10. The customer enjoys a cheap vacation!
93. Sprint 1: Walking skeleton
1. A customer wants cheap vacations
2. The customer signs up for daily or weekly notifications of special
flight offers
3. Periodically the System checks which customers should get
notifications
4. The System checks for offers that matches the customer’s travel
preference by looking up flights with the travel provider system
5. The System notifies customer of any matching offers via SMS
• Variation: The System notifies customer of any matching offers via
email
6. The customer accepts the offer via SMS
1. Variation: The customer accepts the offer on the system website
7. The System books the tickets on behalf of the customer
8. The system confirms the booking by sending an SMS to the
customer
9. The customer can at any point see their active offers and accepted
offers on the system website
10. The customer enjoys a cheap vacation!
94. Sprint 2: SMS support
1. A customer wants cheap vacations
2. The customer signs up for daily or weekly notifications of special
flight offers
3. Periodically the System checks which customers should get
notifications
4. The System checks for offers that matches the customer’s travel
preference by looking up flights with the travel provider system
5. The System notifies customer of any matching offers via SMS
• Variation: The System notifies customer of any matching offers via
email
6. The customer accepts the offer via SMS
1. Variation: The customer accepts the offer on the system website
7. The System books the tickets on behalf of the customer
8. The system confirms the booking by sending an SMS to the
customer
9. The customer can at any point see their active offers and accepted
offers on the system website
10. The customer enjoys a cheap vacation!
95. Sprint 3: Complete workflow
1. A customer wants cheap vacations
2. The customer signs up for daily or weekly notifications of special
flight offers
3. Periodically the System checks which customers should get
notifications
4. The System checks for offers that matches the customer’s travel
preference by looking up flights with the travel provider system
5. The System notifies customer of any matching offers via SMS
• Variation: The System notifies customer of any matching offers via
email
6. The customer accepts the offer via SMS
1. Variation: The customer accepts the offer on the system website
7. The System books the tickets on behalf of the customer
8. The system confirms the booking by sending an SMS to the
customer
9. The customer can at any point see their active offers and accepted
offers on the system website
10. The customer enjoys a cheap vacation!
96. Sprint 4: Complete SMS
1. A customer wants cheap vacations
2. The customer signs up for daily or weekly notifications of special
flight offers
3. Periodically the System checks which customers should get
notifications
4. The System checks for offers that matches the customer’s travel
preference by looking up flights with the travel provider system
5. The System notifies customer of any matching offers via SMS
• Variation: The System notifies customer of any matching offers via
email
6. The customer accepts the offer via SMS
1. Variation: The customer accepts the offer on the system website
7. The System books the tickets on behalf of the customer
8. The system confirms the booking by sending an SMS to the
customer
9. The customer can at any point see their active offers and accepted
offers on the system website
10. The customer enjoys a cheap vacation!
97. Sprint 5: Web pages
1. A customer wants cheap vacations
2. The customer signs up for daily or weekly notifications of special
flight offers
3. Periodically the System checks which customers should get
notifications
4. The System checks for offers that matches the customer’s travel
preference by looking up flights with the travel provider system
5. The System notifies customer of any matching offers via SMS
• Variation: The System notifies customer of any matching offers via
email
6. The customer accepts the offer via SMS
1. Variation: The customer accepts the offer on the system website
7. The System books the tickets on behalf of the customer
8. The system confirms the booking by sending an SMS to the
customer
9. The customer can at any point see their active offers and accepted
offers on the system website
10. The customer enjoys a cheap vacation!
98. Sprint 7: Integration
1. A customer wants cheap vacations
2. The customer signs up for daily or weekly notifications of special
flight offers
3. Periodically the System checks which customers should get
notifications
4. The System checks for offers that matches the customer’s travel
preference by looking up flights with the travel provider system
5. The System notifies customer of any matching offers via SMS
• Variation: The System notifies customer of any matching offers via
email
6. The customer accepts the offer via SMS
1. Variation: The customer accepts the offer on the system website
7. The System books the tickets on behalf of the customer
8. The system confirms the booking by sending an SMS to the
customer
9. The customer can at any point see their active offers and accepted
offers on the system website
10. The customer enjoys a cheap vacation!
99. Sprint 8: Spit-and-polish
1. A customer wants cheap vacations
2. The customer signs up for daily or weekly notifications of special
flight offers
3. Periodically the System checks which customers should get
notifications
4. The System checks for offers that matches the customer’s travel
preference by looking up flights with the travel provider system
5. The System notifies customer of any matching offers via SMS
• Variation: The System notifies customer of any matching offers via
email
6. The customer accepts the offer via SMS
1. Variation: The customer accepts the offer on the system website
7. The System books the tickets on behalf of the customer
8. The system confirms the booking by sending an SMS to the
customer
9. The customer can at any point see their active offers and accepted
offers on the system website
10. The customer enjoys a cheap vacation!